Looking to the future, we are likely to want to support adding resources to a job (in addition to releasing resources). To extend PBS Pro to add resources to jobs (in the future), it would be valuable to design this feature (today) to be easily extendable (syntax and accounting) and to fit naturally with that future direction.
For the “add resources” CLI/API, the natural opposite of pbs_release_nodes would be pbs_add_nodes, but that seems very unnatural and un-PBS-y. A better choice would be to use the existing PBS resource request language (-l select=XYZ) to either:
- add resources, e.g., pbs_add_resources -l select=XYZ …
- or replace the job’s resources, e.g., pbs_resize_resources -l selectXYZ" …
The latter obviously could be used for either adding or releasing, and has the design advantages of:
(a) using the existing PBS syntax,
(b) having PBS handle the calculation of which chunks are on which nodes, and
© naturally supporting both node-level and job-wide resources (e.g., expensive software licenses).
(Note: “pbs_release_nodes -a” does have all the above design advantages.)
I particularly don’t like the idea of forcing the user to do work that could be automated by PBS, so (b) strikes me as particularly onerous. (Allowing node names as an option is good; having them as the only option is not so nice.)
Even more than the CLI/API, I feel it is really important to ensure the accounting records will handle the add case (in addition to the release case), as the whole PBS Pro ecosystem builds tools that depend on and consume the accounting records. Here I am not not sure whether it would work or not… would the proposed new u, c, and e records also work for adding/resizing in general? Would we need any changes in them to support adding resources?