Problem: Queue membership is defined indirectly. An admin assigns
a resource property to nodes, then binds a queue to it with
queues.NAME.requires. In practice nearly every configuration uses
one property per queue named after the queue, so the indirection
forces tools to re-implement the property-to-queue join and offers
no way to validate membership.
Add an optional queues.NAME.hosts key that declares queue membership
directly as an RFC 29 Hostlist (or the literal "all"). Flux then
derives the queue's membership property, the queue name prefixed
with the RFC 20 "+" marker, applies it to the named hosts, and
adds the equivalent {"properties": ["+NAME"]} constraint to jobs
submitted to the queue. Define the hostlist as the preferred way
to define membership and note that requires may be deprecated in a
future version.
Assisted-by: Claude:Opus-4.8
Problem: RFC 33 queue membership is defined indirectly. An admin assigns a resource property to nodes, then binds a queue to it with queues.NAME.requires. In practice nearly every configuration uses one property per queue named after the queue, so the indirection forces tools to re-implement the property-to-queue join and offers no way to validate membership.
Add an optional queues.NAME.hosts key that declares queue membership directly as an RFC 29 Hostlist (or the literal string "all"). In this case, the queue property is then implicitly assigned the queue name, and jobs have the proper constraint automatically assigned. Properties that match queue names are then reserved. Document in the spec that hosts is the preferred method for defining queues, and that
requiresmay be deprecated in the future.Assisted-by: Claude:Opus-4.8