rfc25: clarify V1 restrictions in tasks section #441
Conversation
Problem: the current Tasks section simply refers back to RFC14, despite there being several noteworthy restrictions in V1 vs canonical jobspec. Elucidate the restrictions on the count key and its subkeys for V1.
Problem: JSON schema doesn't fully reflect V1 restrictions for tasks. Modify "count" to require anyOf "per_slot" and/or "total" and constrain "per_slot" to a "const" value of 1.
spec_25.rst
Outdated
|
|
||
| - total | ||
|
|
||
| If both of these keys are set, the last key parsed SHALL prevail. The definitions of these keys SHALL match those provided in :doc:`RFC 14 <spec_14>`, with the following restrictions in V1: if ``per_slot`` is used, it's value MUST be one, and if ``total`` is used it's value MUST be less than or equal to the ``count`` key of the associated slot and greater than or equal to the number of allocated nodes (if no ``node`` resource vertex is explicitly given in the jobspec, then this minimum value will depend on the instance resource configuration and/or scheduler used). |
There was a problem hiding this comment.
I wonder if we want to explicitly forbid both total and per_slot being used, then update the current implementation to enforce it.
There was a problem hiding this comment.
I would personally agree on that being a sensible restriction to make the (intended & actual) behavior of a given jobspec as clear as possible!
There was a problem hiding this comment.
After looking into this a bit further I realized that I was an idiot in my first go-round and was actually overwriting the keys in my Python script, hence why only the last one I specified was being used... mea culpa!
It turns out the actual behavior was that the total is used if both are specified.
There was a problem hiding this comment.
I've also pushed a change reflecting the possible change to exactly one of the keys being required.
There was a problem hiding this comment.
WIP implementation in flux-framework/flux-core#6605
Problem: the desired number of tasks is ambiguous if both total and per_slot are set in tasks.count Specify that exactly one of these keys SHALL be set and modify JSON schema to match.
Problem: the "Tasks" section of RFC 25 basically just points back to RFC 14, but in my testing there does seem to be several noteworthy restrictions on the "count" key that I couldn't find documented anywhere.
This PR is basically my attempt at clarifying what I would have found useful to have in the documentation, based on my best understanding of how the keys seem to behave in my testing. My apologies if I'm not totally correct on the true behavior, but hopefully it won't be too difficult for someone with more knowledge than me to tweak the wordings if necessary!