Added [ironic] topic.
On 10/04/2018 06:06 PM, Chris Friesen wrote:
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.
Ironicers, pay attention to the above! :) It's a green light from Nova
to use the traits list contained in the flavor extra specs and image
metadata when (pre-)configuring an instance.
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.
Ironicers, also pay close attention to the advice above. Things that are
not "scheduleable" -- in other words, things that don't filter the list
of hosts that a workload can land on -- should not go in traits.
Finally, here's the HPET os-traits patch. Reviews welcome (it's tiny patch):
https://review.openstack.org/608258
Best,
-jay
Chris
[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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
