Open Stack

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)

-- 

Thanks,

Matt