On Tue, Apr 9, 2019 at 7:22 PM, Chris Dent <cdent+os@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