Open Stack

On Wed, Oct 1, 2014 at 8:29 AM, Solly Ross <sross at redhat.com> wrote:

> (response inline)
>
> ----- Original Message -----
> > From: "Pasquale Porreca" <pasquale.porreca at dektech.com.au>
> > To: openstack-dev at 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 at 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> Best Regards,
> Solly Ross
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141001/86f731aa/attachment.html>