I thought about this a bit further. I wish we had a clearer separation between:
- leaf queues - queues which jobs can be submitted against
- parent queues - used to manage resources for a set of leaf nodes
I think users will get confused by the fact that you can't have a configuration with root.a.b and root.c.b. If the job submission queues had been kept separate and then a property of the job submission queue described where they attach to the resource hierarchy, it might have been clearer. That way it's very clear where jobs can be submitted, and it's clear that the list of queues where jobs can be submitted is a flat namespace, and it's clear that the hierarchical part of the resource management can be reconfigured without any change to where jobs actually get submitted.
However, the additional gain of making this sort of change to the way queues are defined doesn't seem worth it. We'll just have to be very clear in the documentation that the namespace of the leaves is flat.
This Jira can be used to prevent the RM from accepting configurations where there is a conflict in the list of job submission queues.