(response inline) ----- Original Message ----- > From: "Pasquale Porreca" <pasquale.porr...@dektech.com.au> > To: email@example.com > Sent: Wednesday, October 1, 2014 11:08:50 AM > Subject: Re: [openstack-dev] [nova] Create an instance with a custom uuid > > Thank you for the answers. > > 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 > http://www.ietf.org/rfc/rfc4122.txt ) . > > The generation of the UUID in Nova make use of the function uuid4() from the > module uuid.py 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 uuid.py ). > > In particular I focused my attention on UUID version 1 and the method > uuid1(node=None, clock_seq=None) that allows to pass as parameter a part of > the UUID ( node is the field containing the last 12 hexadecimal digits of > the UUID). > > 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 node .
I would think that we could just have a node parameter here, and automatically use version 1 if that parameter is passed (if we decided to go the route of changing the current UUID behavior). > > Any thoughts? > > On 09/30/14 14:07, Andrew Laski wrote: > > > > On 09/30/2014 06:53 AM, Pasquale Porreca wrote: > > > Going back to my original question, I would like to know: > > 1) Is it acceptable to have the UUID passed from client side? > > 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. > > 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. > > > > > 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. > > > On 09/25/14 17:26, Daniel P. Berrange wrote: > > > On Thu, Sep 25, 2014 at 05:23:22PM +0200, Pasquale Porreca wrote: > > > This is correct Daniel, except that that it is done by the virtual > firmware/BIOS of the virtual machine and not by the OS (not yet installed at > that time). > > This is the reason we thought about UUID: it is yet used by the iPXE client > to be included in Bootstrap Protocol messages, it is taken from the <uuid> > field in libvirt template and the <uuid> in libvirt is set by OpenStack; the > only missing passage is the chance to set the UUID in OpenStack instead to > have it randomly generated. > > Having another user defined tag in libvirt won't help for our issue, since > it won't be included in Bootstrap Protocol messages, not without changes in > the virtual BIOS/firmware (as you stated too) and honestly my team doesn't > have interest in this (neither the competence). > > I don't think the configdrive or metadata service would help either: the OS > on the instance is not yet installed at that time (the target if the network > boot is exactly to install the OS on the instance!), so it won't be able to > mount it. > Ok, yes, if we're considering the DHCP client inside the iPXE BIOS > blob, then I don't see any currently viable options besides UUID. > There's no mechanism for passing any other data into iPXE that I > am aware of, though if there is a desire todo that it could be > raised on the QEMU mailing list for discussion. > > > Regards, > Daniel > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStackfirstname.lastname@example.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- > Pasquale Porreca > > DEK Technologies > Via dei Castelli Romani, 22 > 00040 Pomezia (Roma) > > Mobile +39 3394823805 > Skype paskporr > > _______________________________________________ > OpenStack-dev mailing list > OpenStackemail@example.com > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > Best Regards, Solly Ross _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev