I don't think it's a good feature. Apart from many implementation difficulties, there are logical ones - what happens if the job fails or ends during the activation time? What happens if "during" job cannot be activated immediately due to resource contention?
Gene On 21/07/17 11:18, Lev Lafayette wrote:
Hi Slurmoids, A couple of days ago whilst teaching some Slurm commands I had a bolt of inspiration. I'm not entirely sure of the process of suggested changes to the code base, so I thought I'd elaborate on the concept before going down that path. The idea is for a new dependency, 'during' to add to the set of before, beforeok, beforenotok, after, afterok, afternotok, and singleton. A job with the 'during' dependency will only start if a specified jobID is also running, and would go into a PD (pending) state otherwise and would be submitted in the following manner: `sbatch --dependency=during:jobid:` Like other dependencies multiple job dependencies could be specified. A purpose of such a dependency, apart from a sense of aesthetic completeness, could be for jobs that are providing or receiving information from other running jobs, such as collecting real-time real-time metrics of other running jobs. This will obviously need changes to the slurm_comptetion.sh source, pmi2_api.c and .h, backfill.c, job_scheduler.c, associated binaries, and certainly the manual pages from scontrol, srun, salloc, sbatch, along with the mpi and pbs plugins, along with examples in the testsuite. What do people think? Is this a worthwhile project to explore or have I missed something which is why it hasn't *already* been done? All the best,
-- New Zealand eScience Infrastructure Centre for eResearch The University of Auckland e: [email protected] p: +64 9 3737599 ext 89834 c: +64 21 840 825 f: +64 9 373 7453 w: www.nesi.org.nz
