<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 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 href="mailto:pasquale.porreca@dektech.com.au">pasquale.porreca@dektech.com.au</a>><br>
> To: <a 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 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 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 href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a 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 href="tel:%2B39%203394823805" value="+393394823805">+39 3394823805</a><br>
> Skype paskporr<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a 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 href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a 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>