Closed buchanae closed 6 years ago
Don't think this came from PAPI, not sure where it came from. :+1:
Several batch schedulers implements a suspended/hold state for tasks, but I agree that adds no value to expose it to client. 👍
@pditommaso Do you have some examples? I'd like to do some research on those.
@buchanae for instance i know LSF has it, not sure about SGE. It definitely exists in HPC setups but I question if we should be bringing it forward, the world that TES would be sitting on top of is likely to be a lot more heterogenous than the HPC world (which are all pretty similar once one squints and takes a step back)
@buchanae yes.
PSUSP
, SSUSP
and USUSP
hold statuses.H
status S
(suspended) statusS
and H
status hqw
status. Sorry I don't have a proper link to the documentation of each of them. I getting from the NF source code.
IMO from an application point of view there's no benefit to distinguish between run and hold/suspended statuses. In both cases you need to wait for task completion.
Thanks guys. I can imagine, as a user, wanting to know what my task isn't currently processing and is waiting. For example, if someone asks me how much longer the batch of tasks should take and I know the average runtime, I'll give the wrong estimation if I don't know that some of the tasks are currently paused.
Yes, it could be useful in that way. I'm neutral on this.
This was accidentally merged, but was reverted by another commit. Sounds like we're not sure if we want to remove it. I've created #99 for any further discussion. Sorry for the confusion.
To be clear, the paused state is still in the spec.
This seems like a poorly defined carryover from the Google Genomics API. There's little/no explanation of the behavior of pausing. Can a user pause/unpause? Is pausing controlled solely by the system? If so, does the user need to know that the task is paused?
Not necessarily against the concept of pausing, just trying to cut out the fuzzy parts of the spec until they're clearly defined.