On 6/11/2019 2:46 PM, Eric Fried wrote:
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).
This sounds similar to the ARQ device profile stuff from the nova/cyborg spec [1] - is it?
Also, I'm reminded of the glare/artifactory discussion for baremetal node config we talked about at the PTG in Dublin [2] - how does this compare/contrast?
[1] https://review.opendev.org/#/c/603955/ [2] https://etherpad.openstack.org/p/nova-ptg-rocky (~L250)