Open Stack

>> { groups: [
>>       { requests: [
>>             { resources: {DISK_GB: 10} }
>>         ]
>>       }
>>       { requests: [
>>             { resources: {VCPU: 2, MEMORY_MB: 128} }
>>             { resources: {VF: 1},
>>               required: [NET_A] },
>>             { resources: {VF: 1},
>>               required: [NET_B] },
>>         ],
>>         group_policy: subtree_affinity
>>       },
>>   ]
>> }
> 
> For those of us not in your head, can you explain how the above is
> different/better from the following pseudo-query:
> 
>      resources=DISK_GB;
>      resources1=VCPU:2,MEMORY_MB:128;
>     
> resources2=VF:1;required2=NET_A;group_policy2=subtree_rooter:resources1;
>     
> resources3=VF:1;required2=NET_B;group_policy3=subtree_rooter:resources1
> 
> Apologies if I'm missing some details. I probably am, that's why
> I'm asking. I'm intentionally ignoring your "should not do this by
> making a queryparam ... group numbers" because I didn't fully
> understand the explanation/reasoning in the discussion on the spec,
> so I'm after additional explanation (that is, if we have to merge
> request groups we still need to preserve the distinctiveness of the
> groups, and if some form of a hierarchical relationship is present
> we need to maintain that).

In nova, with the bandwidth (and forthcoming accelerator) code in play,
the group numbers are generated on the fly and in pretty different
sections of the code. But you're right: whether by tracking group
numbers or otherwise, we need some way of clustering the groups
together. That's going to be tricky on the nova side regardless.

Beyond that, I just have a gut ick response to one parameter's *value*
referring to another parameter's *key*. That seems dirty/hacky to me. I
can probably get over it.

>>> * Inventory-less resource providers
>>
>> An interesting topic, but IMO not related to $subject. This will come up
>> as soon as we model NUMA + sharing at all. We shouldn't muddy these
>> waters by hashing it out here.
> 
> I'm sorry to beat on this drum over and over again, but the reason
> to have this pre-PTG stuff is exactly to churn up the waters and get
> all the ideas out in the open so that we are thinking about the
> entire system, not specific details.

Ack. Perhaps I should have said: we're already discussing it in thread
"Resourceless trait filters" [1]. So, lacking any technical connection
to the subject of this thread (true since we killed the idea of using a
trait) we might as well isolate the discussion there.

>> How about we do that in a separate thread, then?
> 
> Why? See my two paragraphs above and my facepalming in another
> thread.

I get it, I just feel like a) this topic is intricate enough in its
technical aspects, we'll have enough of a challenge reaching consensus
without digressing into philosophical tangents; and b) said
philosophical tangents are already being explored in other threads (if
they're not, we should start them). In other words, my preference would
be to keep each thread focused as narrowly as possible. Otherwise we run
the risk of losing sight of the original issue. (I literally just now
had to glance back up at the subject line to remind myself what this
thread was about.)

efried

[1]
http://lists.openstack.org/pipermail/openstack-discuss/2019-April/thread.html#4817