Open Stack

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@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,
after
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>