Open Stack

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) or Vendor
> class identifier (option 60) of the dhcp request to achieve our target,
> but these fields cannot be controlled in libvirt template and so they
> cannot be set in OpenStack either. Instead the UUID is set it the
> libvirt template by OpenStack and it is included in the messages
> exchanged in the pre-boot phase (option 97) by the instance trying to
> boot from network.
>
> Reference:
> http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml
>
>
>
> On 09/25/14 14:43, Andrew Laski wrote:
>>
>> 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
>>>>> <rpodolyaka at mirantis.com <mailto:rpodolyaka at 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.
>>>>>
>>>>> dt
>>>>>
>>>>> --
>>>>>
>>>>> Dean Troyer
>>>>> dtroyer at gmail.com <mailto:dtroyer at gmail.com>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>
>>>> 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
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

If it's a matter of getting the instance tag information down to the 
libvirt driver on boot that shouldn't be a problem, there are others 
asking for similar things, i.e. I want to tag my instances at create 
time and store that tag metadata in some namespace in the libvirt domain 
xml so I can have an application outside of openstack consuming those 
domain xml's and reading that custom namespace information.

-- 

Thanks,

Matt Riedemann