Open Stack

On Tue, Apr 9, 2019 at 7:22 PM, Chris Dent <cdent+os at anticdent.org> 
wrote:
> 
> From the etherpad [1] (the cross project one):
> 
> * This came up with the effort to add a multiattach capability
>   filter, at 
> https://review.openstack.org/#/c/645316/1/nova/compute/api.py@1098

Just for completness. In the above linked example, requesting the trait 
was the problem. It was requested in a separate numbered request group 
that had no requested resources. Today that is invalid in the placement 
a_c API.

> 
> * The problem: we want to be able to request allocation candidates
>   filtered by a trait that exists on the root provider; but
> 
>     * (a) the root provider may provide no resources (eventually -
>       e.g. CPU/mem in NUMA providers, shared disk); and/or
> 
>         * (My brain hurts from the concept for a provider that
>           provides nothing. Perhaps it provides something we aren't
>           remembering to count?)

Since providers can be nested a provider can be a strucutral element in 
a nested tree without providing resources. This happens in the 
bandwidth case where the agent RPs are there to connect the device RPs 
to neutron agents. It is bit like a resource provider partitioning 
scheme as well as RP ownership definition implemented by nested 
subtrees. To avoid the trait on an empty RP problem in this case all 
the traits are added to the device RPs even if some of the traits 
(CUSTOM_VNIC_TYPE_XXX) are more logically belong to the agnet RP. I'm 
currently happy with the resulting RP tree and trait handling in the 
bandwidth model.

> 
>     * (b) we are using only numbered groups and would have to guess
>       where to stuff the `required` - again probably based on
>       looking for the VCPU/mem resources, which, as above, may wind
>       up not on the root provider.
> 
> This, basically, is how/when do we deal with resource providers that
> have traits but have no classes of inventory of their own (all of it
> is on their descendants). The "My brain hurts" comment above is
> mine.

I think the possible solution to move the trait down to the RP that 
provides the resources that has a capability described by the trait 
could be a simple solution that does not require placement changes.

> 
> The discussion on the review above (good backgrounder for this
> thread) had little to do with the immediate need of the proposed
> feature. It was a concern about how things will work in the future.
> So there are two salient questions (and presumably plenty of other
> sidebars):
> 
> * How should it work?
> * What is the timeline for when it needs to work?

I think this work should be driven by a specific need, like the NUMA 
modelling in placement by nova. What is the timeline of NUMA modelling 
in placement?

Cheers,
gibi

> 
> [1] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement
> 
> 
> --
> Chris Dent                       ٩◔̯◔۶           
> https://anticdent.org/
> freenode: cdent                                         tw: @anticdent