<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi all,<br>
    while I was working on blueprint Pasquale addressed this issue. <br>
    In the use case explained  both features are involved<br>
    but the user defined UUID does not depend strictly on original
    blueprint but it can be a new one.<br>
    If there is no objection I could write a blueprint/specification
    regarding to last solution.<br>
    Any thought?<br>
    <br>
    BR,<br>
    Angelo<br>
    <br>
    <div class="moz-cite-prefix">On 01/10/2014 18:07, Joe Gordon wrote:<br>
    </div>
    <blockquote
cite="mid:CAHXdxOeqVgWkXk5zXu7NNbzg9evPWYhN_QYq5KpDiw3mDKPsGw@mail.gmail.com"
      type="cite">
      <div dir="ltr"><br>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Wed, Oct 1, 2014 at 8:29 AM, Solly
            Ross <span dir="ltr"><<a moz-do-not-send="true"
                href="mailto:sross@redhat.com" target="_blank">sross@redhat.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">(response

              inline)<br>
              <span class=""><br>
                ----- Original Message -----<br>
                > From: "Pasquale Porreca" <<a
                  moz-do-not-send="true"
                  href="mailto:pasquale.porreca@dektech.com.au">pasquale.porreca@dektech.com.au</a>><br>
                > To: <a moz-do-not-send="true"
                  href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
                > Sent: Wednesday, October 1, 2014 11:08:50 AM<br>
                > Subject: Re: [openstack-dev] [nova] Create an
                instance with a custom uuid<br>
                ><br>
                > Thank you for the answers.<br>
                ><br>
                > I understood the concerns about having the UUID
                completely user defined and I<br>
                > also understand Nova has no interest in supporting
                a customized algorithm to<br>
                > generate UUID. Anyway I may have found a solution
                that will cover my use<br>
                > case and respect the standard for UUID (RFC 4122<br>
              </span>> <a moz-do-not-send="true"
                href="http://www.ietf.org/rfc/rfc4122.txt"
                target="_blank">http://www.ietf.org/rfc/rfc4122.txt</a>
              ) .<br>
              <span class="">><br>
                > The generation of the UUID in Nova make use of the
                function uuid4() from the<br>
                > module uuid.py to have an UUID (pseudo)random,
                according to version 4<br>
                > described in RFC 4122. Anyway this is not the only
                algorithm supported in<br>
                > the standard (and implemented yet in uuid.py ).<br>
                ><br>
                > In particular I focused my attention on UUID
                version 1 and the method<br>
                > uuid1(node=None, clock_seq=None) that allows to
                pass as parameter a part of<br>
              </span>> the UUID ( node is the field containing the
              last 12 hexadecimal digits of<br>
              <span class="">> the UUID).<br>
                ><br>
                > So my idea was to give the chance to the user to
                set uiid version (1 or 4,<br>
                > with the latter as default) when creating a new
                instance and in case of<br>
                > version 1 to pass optionally a value for parameter
                node .<br>
                <br>
              </span>I would think that we could just have a node
              parameter here, and automatically<br>
              use version 1 if that parameter is passed (if we decided
              to go the route<br>
              of changing the current UUID behavior).<br>
            </blockquote>
            <div><br>
            </div>
            <div>From what I gather this requested change in API is
              based on for your blueprint <a moz-do-not-send="true"
                href="https://blueprints.launchpad.net/nova/+spec/pxe-boot-instance">https://blueprints.launchpad.net/nova/+spec/pxe-boot-instance</a>.
              Since your blueprint is not approved yet discussing
              further work to improve it is a bit premature.</div>
            <div> <br>
            </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
              <div>
                <div class="h5"><br>
                  ><br>
                  > Any thoughts?<br>
                  ><br>
                  > On 09/30/14 14:07, Andrew Laski wrote:<br>
                  ><br>
                  ><br>
                  ><br>
                  > On 09/30/2014 06:53 AM, Pasquale Porreca wrote:<br>
                  ><br>
                  ><br>
                  > Going back to my original question, I would like
                  to know:<br>
                  ><br>
                  > 1) Is it acceptable to have the UUID passed from
                  client side?<br>
                  ><br>
                  > In my opinion, no. This opens a door to issues we
                  currently don't need to<br>
                  > deal with, and use cases I don't think Nova
                  should support. Another<br>
                  > possibility, which I don't like either, would be
                  to pass in some data which<br>
                  > could influence the generation of the UUID to
                  satisfy requirements.<br>
                  ><br>
                  > But there was a suggestion to look into
                  addressing your use case on the QEMU<br>
                  > mailing list, which I think would be a better
                  approach.<br>
                  ><br>
                  ><br>
                  ><br>
                  ><br>
                  > 2) What is the correct way to do it? I started to
                  implement this feature,<br>
                  > simply passing it as metadata with key uuid, but
                  I feel that this feature<br>
                  > should have a reserved option rather then use
                  metadata.<br>
                  ><br>
                  ><br>
                  > On 09/25/14 17:26, Daniel P. Berrange wrote:<br>
                  ><br>
                  ><br>
                  > On Thu, Sep 25, 2014 at 05:23:22PM +0200,
                  Pasquale Porreca wrote:<br>
                  ><br>
                  ><br>
                  > This is correct Daniel, except that that it is
                  done by the virtual<br>
                  > firmware/BIOS of the virtual machine and not by
                  the OS (not yet installed at<br>
                  > that time).<br>
                  ><br>
                  > This is the reason we thought about UUID: it is
                  yet used by the iPXE client<br>
                  > to be included in Bootstrap Protocol messages, it
                  is taken from the <uuid><br>
                  > field in libvirt template and the <uuid> in
                  libvirt is set by OpenStack; the<br>
                  > only missing passage is the chance to set the
                  UUID in OpenStack instead to<br>
                  > have it randomly generated.<br>
                  ><br>
                  > Having another user defined tag in libvirt won't
                  help for our issue, since<br>
                  > it won't be included in Bootstrap Protocol
                  messages, not without changes in<br>
                  > the virtual BIOS/firmware (as you stated too) and
                  honestly my team doesn't<br>
                  > have interest in this (neither the competence).<br>
                  ><br>
                  > I don't think the configdrive or metadata service
                  would help either: the OS<br>
                  > on the instance is not yet installed at that time
                  (the target if the network<br>
                  > boot is exactly to install the OS on the
                  instance!), so it won't be able to<br>
                  > mount it.<br>
                  > Ok, yes, if we're considering the DHCP client
                  inside the iPXE BIOS<br>
                  > blob, then I don't see any currently viable
                  options besides UUID.<br>
                  > There's no mechanism for passing any other data
                  into iPXE that I<br>
                  > am aware of, though if there is a desire todo
                  that it could be<br>
                  > raised on the QEMU mailing list for discussion.<br>
                  ><br>
                  ><br>
                  > Regards,<br>
                  > Daniel<br>
                  ><br>
                  ><br>
                  ><br>
                  > _______________________________________________<br>
                  > OpenStack-dev mailing list<br>
                  > <a moz-do-not-send="true"
                    href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
                  > <a moz-do-not-send="true"
                    href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                    target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                  ><br>
                  > --<br>
                  > Pasquale Porreca<br>
                  ><br>
                  > DEK Technologies<br>
                  > Via dei Castelli Romani, 22<br>
                  > 00040 Pomezia (Roma)<br>
                  ><br>
                  > Mobile <a moz-do-not-send="true"
                    href="tel:%2B39%203394823805" value="+393394823805">+39

                    3394823805</a><br>
                  > Skype paskporr<br>
                  ><br>
                  > _______________________________________________<br>
                  > OpenStack-dev mailing list<br>
                  > <a moz-do-not-send="true"
                    href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
                  > <a moz-do-not-send="true"
                    href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                    target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                  ><br>
                  <br>
                </div>
              </div>
              Best Regards,<br>
              Solly Ross<br>
              <div class="">
                <div class="h5"><br>
                  _______________________________________________<br>
                  OpenStack-dev mailing list<br>
                  <a moz-do-not-send="true"
                    href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
                  <a moz-do-not-send="true"
                    href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
                    target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
                </div>
              </div>
            </blockquote>
          </div>
          <br>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>