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 t
On Wed, Oct 1, 2014 at 8:29 AM, Solly Ross wrote:
> (response inline)
>
> - Original Message -
> > From: "Pasquale Porreca"
> > To: openstack-dev@lists.openstack.org
> > Sent: Wednesday, October 1, 2014 11:08:50 AM
> > Subject: Re: [openstack-d
(response inline)
- Original Message -
> From: "Pasquale Porreca"
> 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 an
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
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?
FWIW, Glance has supported supplying the newly-created image's ID in its
API for a long time, and it's never been an issue. O
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 shoul
Going back to my original question, I would like to know:
1) Is it acceptable to have the UUID passed from client side?
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 opt
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 iP
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 fro
On Thu, Sep 25, 2014 at 09:19:03AM -0500, Matt Riedemann wrote:
>
>
> On 9/25/2014 8:26 AM, Pasquale Porreca wrote:
> >The problem to use a different tag than UUID is that it won't be
> >possible (for what I know) to include this tag in the Bootstrap Protocol
> >messages exchanged during the pre-
On 9/25/2014 8:26 AM, Pasquale Porreca wrote:
The problem to use a different tag than UUID is that it won't be
possible (for what I know) to include this tag in the Bootstrap Protocol
messages exchanged during the pre-boot phase.
Our original idea was to use the Client-identifier (option 61) o
The problem to use a different tag than UUID is that it won't be
possible (for what I know) to include this tag in the Bootstrap Protocol
messages exchanged during the pre-boot phase.
Our original idea was to use the Client-identifier (option 61) or Vendor
class identifier (option 60) of the d
On 09/25/2014 04:18 AM, Pasquale Porreca wrote:
I will briefly explain our use case. This idea is related to another
project to enable the network boot in OpenStack
https://blueprints.launchpad.net/nova/+spec/pxe-boot-instance
We want to make use of the extra-dhcp-opt to indicate as tftp serv
I will briefly explain our use case. This idea is related to another
project to enable the network boot in OpenStack
https://blueprints.launchpad.net/nova/+spec/pxe-boot-instance
We want to make use of the extra-dhcp-opt to indicate as tftp server a
specific instance inside our deployed system
anks to Joe and rpodolyaka.
Best Regards
Chaoyi Huang ( Joe Huang )
发件人: Joe Gordon [mailto:joe.gord...@gmail.com]
发送时间: 2014年9月25日 1:23
收件人: OpenStack Development Mailing List (not for usage questions)
主题: Re: [openstack-dev] [nova] Create an instance with a custom uuid
Whats the use case f
On 9/24/2014 3:17 PM, Dean Troyer wrote:
On Wed, Sep 24, 2014 at 2:58 PM, Roman Podoliaka
mailto:rpodoly...@mirantis.com>> wrote:
Are there any known gotchas with support of this feature in REST APIs
(in general)?
I'd be worried about relying on a user-defined attribute in that use
c
On Wed, Sep 24, 2014 at 12:58:06PM -0700, Roman Podoliaka wrote:
> Hi Joe,
>
> Tools like Pumphouse [1] (migrates workloads, e.g. instances, between
> two OpenStack clouds) would benefit from supporting this (Pumphouse
> would be able to replicate user instances in a new cloud up to their
> UUIDs)
On Wed, Sep 24, 2014 at 2:58 PM, Roman Podoliaka
wrote:
> Are there any known gotchas with support of this feature in REST APIs
> (in general)?
>
I'd be worried about relying on a user-defined attribute in that use case,
that's ripe for a DOS. Since these are cloud-unique I wouldn't even need
t
Hi Joe,
Tools like Pumphouse [1] (migrates workloads, e.g. instances, between
two OpenStack clouds) would benefit from supporting this (Pumphouse
would be able to replicate user instances in a new cloud up to their
UUIDs).
Are there any known gotchas with support of this feature in REST APIs
(in
Whats the use case for this? We should be thorough when making API changes
like this.
On Wed, Sep 24, 2014 at 6:56 AM, joehuang wrote:
> +1.
>
> Or at least provide a way to specify an external UUID for the instance,
> and can retrieve the instance through the external UUID which may be linked
>
+1.
Or at least provide a way to specify an external UUID for the instance, and can
retrieve the instance through the external UUID which may be linked to external
system's object.
Chaoyi Huang ( joehuang )
发件人: Pasquale Porreca [pasquale.porr...@dektech
21 matches
Mail list logo
