Hi all,
while I was working on blueprint Pasquale addressed this issue.
In the use case explained both features are involved
but the user defined UUID does not depend strictly on original blueprint
but it can be a new one.
If there is no objection I could write a blueprint/specification
regarding to last solution.
Any thought?
BR,
Angelo
On 01/10/2014 18:07, Joe Gordon wrote:
On Wed, Oct 1, 2014 at 8:29 AM, Solly Ross <sr...@redhat.com
<mailto:sr...@redhat.com>> wrote:
(response inline)
----- Original Message -----
> From: "Pasquale Porreca" <pasquale.porr...@dektech.com.au
<mailto:pasquale.porr...@dektech.com.au>>
> To: openstack-dev@lists.openstack.org
<mailto: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
<mailto: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 <tel:%2B39%203394823805>
> Skype paskporr
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
<mailto: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
<mailto: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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
