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 }, ] } Solution 2: Change the data model in some way TBD - your inputs here.
Some of the areas of potential contention:
* Adequate for limited but maybe not all use case solutions
Solution 1 is actually *less* limited than the original proposal, in that it supports the "different nets" bit of the above example. The only limitation that remains I think is that subtrees *have* to start one tier away from the root. And as discussed, there's no known use case where that's a problem.
* Strict trait constructionism
No traits, no contention.
* 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.
* 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.
* 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.
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?
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. efried .