What might be nice is if we could use a flavor extra spec like this:
deploy-config:hyperthreading=enabled
The nova ironic virt driver could pass this to ironic, like it does with traits.
Then in the ironic deploy template, have fields like this:
name: Hyperthreading enabled config-type: hyperthreading config-value: enabled steps: <deploy steps>
Ironic would then match on the config-type and config-value to find a suitable deploy template.
As an extension, the deploy template could define a trait (or list of traits) that must be supported by a node in order for the template to be applied. Perhaps this would even be a standard relationship between config-type and traits?
This.
As rubber has hit road for traits-related-to-config, the pattern that has emerged as (IMO) most sensible has looked a lot like the above.
To get a bit more specific: - HW_CPU_HYPERTHREADING is a trait indicating that a node is *capable* of switching hyperthreading on. There is no trait, ever, anywhere, that indicates that is is on or off on a particular node. - The ironic virt driver tags the node RP with the trait when it detects that the node is capable. - The flavor (or image) indicates a desire to enable hyperthreading as Mark says: via a (non-Placement-ese) property that conveys information in a way that ironic can understand. - A request filter [1] interprets the non-Placement-ese property and adds HW_CPU_HYPERTHREADING as a required trait to the request if it's `enabled`, so the scheduler will ensure we land on a node that can handle it. just an fyi we are adding a request filter to do ^ as part of the pcpu in
On Tue, 2019-06-11 at 14:46 -0500, Eric Fried wrote: placment spec. if you set hw:cpu_thread_polciy=require or hw:cpu_thread_policy=isolate that will be converteded to a required or forbiden trait. in the libvirt driver already uses this to influcne how we pin vms to host cores requing that they land on hyperthreads or requiing the vm uses dedicated cores. ironic could add support for this existing extaspec and the corresponding image property to enable or disabel hyperthreading or SMT to use the generic term.
- During spawn, the ironic virt driver communicates whatever/however to ironic based on the (non-Placement-ese) property in the flavor/image.
Getting back to the original issue of this thread, this still means we need to implement some limited subset of `resize` or rebuild in the image metadata case for ironic to allow us to turn this thing on or off on an established instance. That resize should still go through the scheduler so that, for example, the above process will punt if you try to switch on hyperthreading on a node that isn't capable (doesn't have the HW_CPU_HYPERTHREADING trait).
efried
[1] https://opendev.org/openstack/nova/src/branch/master/nova/scheduler/request_...