auto_accounts needs a relationship to auto_queues

[johrstrom]

From discourse: https://discourse.openondemand.org/t/struggling-to-enable-dynamic-forms/2946

It seems every dynamic account should also populate data-option-for-auto-queue-<QUEUE_NAME>.

[Micket]

Yes, something along this line, the entire "cluster:partition:account:qos" relationship has potentially only partially valid options. I don't happen to use qos this way, but, i think it's possible.

To represent this with data-option-for-xxx one would have to pick a consistent order (doesn't really matter of account has limitations on account or the other way around), but to avoid deadlocks I think one needs to ensure the strategy is something like:

1. cluster (may not have any conditions)
2. partition (may be conditional on cluster)
3. qos (may be conditional on cluster and partition)
4. account (may be conditional on cluster, partition, qos)

otherwise one risks selecting a qos that doens't allow and account, that doesn't allow a paritition that doesn't allow any qos, or some strange deadlock like that where nothing is selectable.

I'll just note that with a setup with private partitions, most users will only ever have access to at most 2 (main partition and maybe 1 private partition) out of ~10 partitions, so best would be not to present the options that don't have any valid accounts at all.
I guess this could apply to cluster, partitions and qos all the same.

[johrstrom]

I'm looking into this a bit now. I think I'll have to revert #2594 and allow for duplicates in any given list to be populated.

[johrstrom]

I put some work into this for the 3.1 release, though I can't say it's finished. If you could provide some sacctmgr output or sinfo output or similar to test against that'd be super helpful. We don't really expose queues to our customers so it's I'm struggling a bit to meet the needs of sites that do without something to test against.