{ 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.htm...