<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Thank you for the answers.<br>
    <br>
    I understood the concerns about having the UUID completely user
    defined and I also understand Nova has no interest in supporting a
    customized algorithm to generate UUID. Anyway I may have found a
    solution that will cover my use case and respect the standard for
    UUID (RFC 4122 <a class="moz-txt-link-freetext"
      href="http://www.ietf.org/rfc/rfc4122.txt">http://www.ietf.org/rfc/rfc4122.txt</a>)
    .<br>
    <br>
    The generation of the UUID in Nova make use of the function <i>uuid4()</i>
    from the module <i>uuid.py</i> to have an UUID (pseudo)random,
    according to version 4 described in RFC 4122. Anyway this is not the
    only algorithm supported in the standard (and implemented yet in <i>uuid.py</i>).<br>
    <br>
    In particular I focused my attention on UUID version 1 and the
    method <i>uuid1(node=None, clock_seq=None)</i> that allows to pass
    as parameter a part of the UUID (<i>node</i> is the field containing
    the last 12 hexadecimal digits of the UUID). <br>
    <br>
    So my idea was to give the chance to the user to set uiid version (1
    or 4, with the latter as default) when creating a new instance and
    in case of version 1  to pass optionally a value for parameter <i>node</i>.<br>
    <br>
    Any thoughts? <br>
    <br>
    <div class="moz-cite-prefix">On 09/30/14 14:07, Andrew Laski wrote:<br>
    </div>
    <blockquote cite="mid:542A9CEA.1010405@rackspace.com" type="cite"> <br>
      On 09/30/2014 06:53 AM, Pasquale Porreca wrote: <br>
      <blockquote type="cite">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>
      </blockquote>
      <br>
      In my opinion, no.  This opens a door to issues we currently don't
      need to deal with, and use cases I don't think Nova should
      support. Another possibility, which I don't like either, would be
      to pass in some data which 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 mailing list, which I think would be a better
      approach. <br>
      <br>
      <blockquote type="cite"> <br>
        2) What is the correct way to do it? I started to implement this
        feature, simply passing it as metadata with key uuid, but I feel
        that this feature should have a reserved option rather then use
        metadata. <br>
        <br>
        <br>
        On 09/25/14 17:26, Daniel P. Berrange wrote: <br>
        <blockquote type="cite">On Thu, Sep 25, 2014 at 05:23:22PM
          +0200, Pasquale Porreca wrote: <br>
          <blockquote type="cite">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>
          </blockquote>
          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>
        </blockquote>
        <br>
      </blockquote>
      <br>
      <br>
      _______________________________________________ <br>
      OpenStack-dev mailing list <br>
      <a class="moz-txt-link-abbreviated"
        href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
      <br>
      <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>
      <br>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr</pre>
  </body>
</html>