While discussing the "Add HPET timer support for x86 guests" blueprint[1] one of the items that came up was how to represent what are essentially flags that impact both scheduling and configuration. Eric Fried posted a spec to start a discussion[2], and a number of nova developers met on a hangout to hash it out. This is the result.

In this specific scenario the goal was to allow the user to specify that their image required a virtual HPET. For efficient scheduling we wanted this to map to a placement trait, and the virt driver also needed to enable the feature when booting the instance. (This can be generalized to other similar problems, including how to specify scheduling and configuration information for Ironic.)

We discussed two primary approaches:

The first approach was to specify an arbitrary "key=val" in flavor extra-specs or image properties, which nova would automatically translate into the appropriate placement trait before passing it to placement. Once scheduled to a compute node, the virt driver would look for "key=val" in the flavor/image to determine how to proceed.

The second approach was to directly specify the placement trait in the flavor extra-specs or image properties. Once scheduled to a compute node, the virt driver would look for the placement trait in the flavor/image to determine how to proceed.

Ultimately, the decision was made to go with the second approach. The result is that it is officially acceptable for virt drivers to key off placement traits specified in the image/flavor in order to turn on/off configuration options for the instance. If we do get down to the virt driver and the trait is set, and the driver for whatever reason determines it's not capable of flipping the switch, it should fail.

It should be noted that it only makes sense to use placement traits for things that affect scheduling. If it doesn't affect scheduling, then it can be stored in the flavor extra-specs or image properties separate from the placement traits. Also, this approach only makes sense for simple booleans. Anything requiring more complex configuration will likely need additional extra-spec and/or config and/or unicorn dust.


[1] https://blueprints.launchpad.net/nova/+spec/support-hpet-on-guest
[2] https://review.openstack.org/#/c/607989/1/specs/stein/approved/support-hpet-on-guest.rst

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to