rfc31: add format for the specification of job constraints #314
Conversation
grondo
changed the title
There was a problem hiding this comment.
decided it would be cleaner to propose a separate RFC for job constraints rather than adding separately to each of the jobspec RFCs. We can then refer to this RFC when describing where constraints go in the jobspec RFCs, as we have done with dependencies.
I think that was the right move. This looks good as is!
This reverts commit d3139d2. Revert accidentally committed RFC 31 so it can be proposed in its own PR.
Problem: There is no defintion of how to encode job constraints in a standardized format. Introduce RFC 31: Job Constraints Specification, which includes a simple, but extensible format for encoding job constraints, inspired by the json-logic definition at https://jsonlogic.com.
|
Ok, what I've done is revert the accidental commit and then committed it again immediately on top so that it can properly be merged in this PR. If the original was acceptable we could optionally close this PR and make changes in future PRs. |
We have used attributes.system.scheduler.queue to capture queue name constraints. I have a slight preference to use Having said that, do you see a user case of properties beyond scheduler constraints? In case you have a specific reason to use |
|
Here is my main argument against Since the main purpose of jobspec is to express program requirements to the scheduler, I find a separate Since |
|
@grondo: that's a good argument. Keeping generic properties at a higher level and scheduler-specific parameters under |
|
closing this one since RFC 31 was merged in a separate PR |
This is a first cut proposal for encoding generic job constraints in a JSON object for inclusion in jobspec.
The proposed format is general enough to allow fairly complex matching (in case this is ever required), but in its simplest form, looks identical to the initial proposal in flux-framework/flux-core#4143, i.e.
attributes.system.constraints.properties=[ array of required properties ].The format is largely inspired by JsonLogic.
I decided it would be cleaner to propose a separate RFC for job constraints rather than adding separately to each of the jobspec RFCs. We can then refer to this RFC when describing where constraints go in the jobspec RFCs, as we have done with dependencies.
Fixes #243
Fixes #246