<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Chris Dent <<a href="mailto:cdent%2Bos@anticdent.org">cdent+os@anticdent.org</a>> 于2019年4月10日周三 上午1:31写道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
>From the etherpad [1] (the cross project one):<br>
<br>
* This came up with the effort to add a multiattach capability<br>
   filter, at <a href="https://review.openstack.org/#/c/645316/1/nova/compute/api.py@1098" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/645316/1/nova/compute/api.py@1098</a><br>
<br>
* The problem: we want to be able to request allocation candidates<br>
   filtered by a trait that exists on the root provider; but<br>
<br>
     * (a) the root provider may provide no resources (eventually -<br>
       e.g. CPU/mem in NUMA providers, shared disk); and/or<br>
<br>
         * (My brain hurts from the concept for a provider that<br>
           provides nothing. Perhaps it provides something we aren't<br>
           remembering to count?)<br>
<br>
     * (b) we are using only numbered groups and would have to guess<br>
       where to stuff the `required` - again probably based on<br>
       looking for the VCPU/mem resources, which, as above, may wind<br>
       up not on the root provider.<br></blockquote><div><br></div><div>Yea, just take a look at this spec <a href="https://review.openstack.org/#/c/647578/4">https://review.openstack.org/#/c/647578/4</a>, after</div><div>we have NUMA in Placement, then the VCPU/mem in the child NUMA RP, but those</div><div>traits are still in the root provider.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
This, basically, is how/when do we deal with resource providers that<br>
have traits but have no classes of inventory of their own (all of it<br>
is on their descendants). The "My brain hurts" comment above is<br>
mine.<br>
<br>
The discussion on the review above (good backgrounder for this<br>
thread) had little to do with the immediate need of the proposed<br>
feature. It was a concern about how things will work in the future.<br>
So there are two salient questions (and presumably plenty of other<br>
sidebars):<br>
<br>
* How should it work?<br>
* What is the timeline for when it needs to work?<br>
<br>
[1] <a href="https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement</a><br>
<br>
<br>
-- <br>
Chris Dent                       ٩◔̯◔۶           <a href="https://anticdent.org/" rel="noreferrer" target="_blank">https://anticdent.org/</a><br>
freenode: cdent                                         tw: @anticdent</blockquote></div></div>