This sounds a bit like the jobpacks stuff that is in development right now. It's more focused on heterogeneous computing but really, at the core, it's done as multiple jobs that run simultaneously and then merged (I think).
But more in general, you could imagine a "service" queue one one set of resources that might allow users to run long running things, like for example mongo or other database-type instance. You would only want dependent jobs to run _during_ the much longer running database or controller job. I think the more general capability is a good idea. ---- Doug Jacobsen, Ph.D. NERSC Computer Systems Engineer National Energy Research Scientific Computing Center <http://www.nersc.gov> [email protected] ------------- __o ---------- _ '\<,_ ----------(_)/ (_)__________________________ On Thu, Jul 20, 2017 at 4:33 PM, Lev Lafayette <[email protected] > wrote: > On Fri, 2017-07-21 at 11:21 +1200, Gene Soudlenkov wrote: > > 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? > > The test is only a dependency for initiation. If the dependent job fails > during activation time, it will still launch and probably do nothing > interesting. If it can't launch due to resource contention then it > doesn't launch. It's not going to be killing other jobs :) > > > -- > Lev Lafayette, BA (Hons), GradCertTerAdEd (Murdoch), GradCertPM, MBA > (Tech Mngmnt) (Chifley) > HPC Support and Training Officer +61383444193 +61432255208 > Department of Infrastructure Services, University of Melbourne > >
