Open Stack

(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).

> 
> 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