Open Stack

> 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.
- 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` 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_filter.py