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
<[email protected] <mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
_______________________________________________
OpenStack-dev mailing list
[email protected]
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
[email protected]
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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
