a) It assumes the meaning of "same tree" is "one level down from the root".
Does it? I had casually interpreted "group_policy=same_tree:$GROUP_A:$GROUP_B" as meaning '$GROUP_B is somewhere within the tree rooted at $GROUP_A at any level' but it could just as easily be interpreted a few different ways, including what you say.
If I interpret that ^ correctly, it would require $GROUP_A (the subtree root) to provide resources, a scenario for which we have at least one counterexample (the one with network agents as resourceless providers).
Jay suggested extending the JSON schema to allow groups that are names like resources_compute, required_network. That might allow for some conventions to emerge but still requires some measure of knowledge from the participants.
I think this is a good idea to pursue, because it gives us a way to predefine (by convention) what the groups are called, as opposed to having them be automatically, arbitrarily, unpredictably numbered. It'll still break down in more complex scenarios where, say, there's more than one device_group with different affinity requirements; but it could work for the simpler setups.
Also good is making sure that from placement's standpoint the knowledge is merely symbolic.
Sure. Just like the group numbers, the names would be just as arbitrary/symbolic as the group numbers are today. And since we're talking about reporting group_num/resource_provider association, those symbols need to survive for the duration of the GET /a_c operation, but no longer than that. efried .