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 server a specific instance inside our deployed system, so it will provide the right operating system to the other instances booting from network (once the feature from the linked blueprint will be implemented).

On the tftp server we want to be able to filter what boot file to provide to different class of instances and our idea was to identify each class with 2 hexadecimal of the UUID (while the rest would be random generated, still "granting" its uniqueness).

It seems like this would still be achievable using the instance tags feature that Matt mentioned. And it would be more clear since you could use human readable class names rather than relying on knowing that part of the UUID had special meaning.

If you have a need to add specific information to an instance like 'boot class' or want to indicate that an instance in two different clouds is actually the same one, the Pumphouse use case, that information should be something we layer on top of an instance and not something we encode in the UUID.

Anyway this is a customization for our specific environment and for a feature that is still in early proposal stage, so we wanted to propose as a separate feature to allow user custom UUID and manage the generation out of OpenStack.
On 09/24/14 23:15, Matt Riedemann wrote:

On 9/24/2014 3:17 PM, Dean Troyer wrote:
On Wed, Sep 24, 2014 at 2:58 PM, Roman Podoliaka
<rpodoly...@mirantis.com <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
case, that's ripe for a DOS.  Since these are cloud-unique I wouldn't
even need to be in your project to block you from creating that clone
instance if I knew your UUID.



Dean Troyer
dtro...@gmail.com <mailto:dtro...@gmail.com>

OpenStack-dev mailing list

We talked about this a bit before approving the 'enforce-unique-instance-uuid-in-db' blueprint [1]. As far as we knew there was no one using null instance UUIDs or duplicates for that matter.

The instance object already enforces that the UUID field is unique but the database schema doesn't. I'll be re-proposing that for Kilo when it opens up.

If it's a matter of tagging an instance, there is also the tags blueprint [2] which will probably be proposed again for Kilo.

[1] https://blueprints.launchpad.net/nova/+spec/enforce-unique-instance-uuid-in-db
[2] https://blueprints.launchpad.net/nova/+spec/tag-instances

OpenStack-dev mailing list

Reply via email to