On Sun, 28 Apr 2019, Eric Fried wrote:
We've talked about this previously. The two objections raised were:
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.
b) It assumes the various pieces of the request (flavor, image, port, device profile) are able to know each others' request group numbers ahead of time. Or we need provide some other mechanism for the scheduler code that dynamically assigns the numbers [2] to understand which ones need to be (sub)grouped together. IIUC this has been Sundar's main objection.
As I understand things, this is going to be a problem in most of the proposals, for at least one of the many participants in the interactions that lead to a complex workload landing. 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 suspect some form of knowledge is going to be needed. Limiting it would be good. Also good is making sure that from placement's standpoint the knowledge is merely symbolic. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent