[openstack-dev] [nova] agreement on how to specify options that impact scheduling and configuration
chris.friesen at windriver.com
Thu Oct 4 22:06:30 UTC 2018
While discussing the "Add HPET timer support for x86 guests"
blueprint 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, 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.
More information about the OpenStack-dev