rfc33: define queue membership by hostlist - #544
Open
grondo wants to merge 2 commits into
Open
Conversation
|
|
Contributor
Author
|
Hold off on reviewing this. It might be nice to make automatically assigned queue properties marked in some way, e.g. with a |
Problem: There is no way to differentiate properties in a resource set that were applied automatically by Flux apart from a property configured manually, so tooling cannot know which properties describe the instance versus the resources. This leads to allocated R objects inheriting properties that may have no meaning in a subinstance. Reserve a leading + in a property name to mark a property that Flux added automatically rather than one configured manually. The literal property still applies to its execution target ranks, but because it describes the containing instance it is intended for internal use and MAY be omitted from a resource set allocated to a job. Assisted-by: Claude:Opus-4.8
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
grondo
force-pushed
the
rfc33-queue-hosts
branch
from
August 1, 2026 15:37
bf38d91 to
b7d25f2
Compare
|
|
Contributor
Author
|
Ok, now based on top of #545. A leading |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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