On Wed, 10 Apr 2019, Eric Fried wrote:
I feel like good progress is occurring in the
As of this writing, I'm backing totally off of the solution proposed there and instead favoring one of:
Solution 1: Assume "subtree" means "exactly one tier away from the root" and express groupings of, er, request groups as needing to come from "the same subtree". We should *not* do this by making a queryparam whose value contains request group numbers, for reasons explained in the spec/comments. Any other attempt to represent groups-of-request-groups in a querystring is (IMO) untenable, so we should cut over to accepting the query as a JSON payload. Here's a sample of what it would look like for, "give me proc, mem, and two different nets, all from the same NUMA node; and disk from wherever":
{ 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). To be clear, I'm not trying to block the JSON body, I'm trying to understand. That is: my request for an explanation of the differences is exactly that.
* Evolving the complexity of placement solely for the satisfaction of hardware representation in Nova
Mm. I get that it would be nice to identify non-Nova needs for this feature, but hopefully you're not suggesting that we should avoid doing it if we can't find some.
As I said on the spec at https://review.openstack.org/#/c/650476/1/doc/source/specs/train/approved/20... "a way that placement can work that happens to satisfy NUMA" (using placement-related primitives) as opposed to making a solution that is directly modeled off NUMA concepts. I'm pretty sure we're not doing the latter, but it is a thing to be aware of while having a wide-open conversation (which is what this is). I'm _not_ suggesting we avoid 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.
* Developing new features in placement before existing features are fully used in client services
Are we not pretty close on this? Are there any placement features that don't have client uses either already implemented or proposed for Train? Again, IMO not a thing to even consider blocking on. And also not specific to this topic.
It's nothing to do with blocking, it's about being aware. Strict adherence to thread discipline is not desired in this process. Ramble. Talk. Spitball. We have the time. Use it.
I list this not because they are deal breakers or the only thing that matters, but because they have presented stumbling blocks in the past and we may as well work to address them (or make an agreement to punt them until later) otherwise there will be lingering dread.
How about we do that in a separate thread, then?
Why? See my two paragraphs above and my facepalming in another thread.
We'd like to figure out the best solution that can actually be done in a reasonable amount of time, not the best solution in the absolute.
Yeah, so to that point, I fear analysis paralysis if we decide to go JSON query, trying to get the schema absolutely perfect. Parity with the existing querystring impl plus the subtree affinity feature ought to be good enough to start with.
I suspect if we can come up a sufficient explanation for why query params are not gonna do it (which might be relatively painless) we might, if we give ourselves the leeway to hash it out effectively, come up with a reasonable set of constraints for an initial version (which we have license to evolve). -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent