Jay Pipes <jaypi...@gmail.com> 于2018年10月5日周五 下午9:25写道:
> 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. > ++, see I talk about the same thing before https://review.openstack.org/#/c/504952/5/specs/approved/config-template-traits.rst@95 :) > > 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 >
__________________________________________________________________________ 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