Open Stack

On Tue, 2019-06-11 at 14:46 -0500, 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.
just an fyi we are adding  a request filter to do ^ as part of the pcpu in
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_filter.py
>