Dong H. Ahn

Thanks. At first glance, it seems to require a multi-step investigation. It is hard to scope how much work will be needed when we don't even have a simple multiqueue...

>If you allowed a property, say exclusive, to be attached to each resource, `exclusive` is already a key of a resource so that this can be done through that key....

Thinking again this morning, jobspec splitting won't work either because this way you won't be able to express higher level locality constraints like: ``` cluster[1]->rack[1]->node[1]->core[1] ->node[2]->core[40] ``` So... want to...

@jameshcorbett: Hmmm it looks to me like quite involved. One path forward would be actually to combine both ideas: on-the-fly jobspec splitting and subtree loop traversal. I was trying to...

Another potentially easier viable path would be still use one-path traversal with some match test tweaks which should require many architectural changes... Currently the main reason that same resource-typed sibling...

Yes, this can be done fairly easily by allowing the predefined writer name as an optional argument. The first real use case for `find` was for `flux resource list` which...

Yup, this makes a lot of sense. Since resource uses recursive algorithms, how we will bubble up the reasons for an unmatch to the upper layer requires some thoughts. Let's...

Maybe we can have some log print statements when traverser return `-1` from either depth first walk.

Do we need more logging than the current method? We do log whether a job cannot be scheduled because of satisfiability or internal bug or just a lack of resources...

> Are sparse jobspec requests still not supported? Would it have any other unintended side effects for jobspec creation and/or to introduce extra hierarchy by making chunks children of the...