Open Stack

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