[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[placement][nova][ptg] Resourceless trait filters

Chris Dent <cdent+os at anticdent.org> äº?2019å¹´4æ??10æ?¥å?¨ä¸? ä¸?å??1:31å??é??ï¼?

> 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 at 1098
> * 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?)
>      * (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.

Yea, just take a look at this spec https://review.openstack.org/#/c/647578/4,
we have NUMA in Placement, then the VCPU/mem in the child NUMA RP, but those
traits are still in 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.
> 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?
> [1] https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement
> --
> Chris Dent                       Ù©â??̯â??Û¶           https://anticdent.org/
> freenode: cdent                                         tw: @anticdent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/b7838d6a/attachment.html>