Open Stack

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