On Wed, Oct 1, 2014 at 8:29 AM, Solly Ross <sr...@redhat.com> wrote: > (response inline) > > ----- Original Message ----- > > From: "Pasquale Porreca" <pasquale.porr...@dektech.com.au> > > To: openstack-dev@lists.openstack.org > > 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). >
>From what I gather this requested change in API is based on for your blueprint https://blueprints.launchpad.net/nova/+spec/pxe-boot-instance. Since your blueprint is not approved yet discussing further work to improve it is a bit premature. > > > > > 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 > > OpenStack-dev@lists.openstack.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 > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > Best Regards, > Solly Ross > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev