Make cylc hold more visible
ColemanTom opened this issue · comments
Problem
I've got much more interest in doing hold rather than pause. I often want to hold a workflow, and submit individual tasks.
Proposed Solution
- Make
Holdand Release visible by default and not hidden behindSee more - Ideally have it (and release) as an option outside of the dropdown menu for very quick access
What do you mean by 2 exactly? (Hold and release are task-specific, so you need to get a task menu).
Hold/Release is available from the top menu, not just at the task level. They provide a default of */* which you can modify.
I would like to have Hold-all/Release-all (automatically keeps it as */*) in a similar area to the Play/Pause buttons.
Ah, got it, thanks.
Note we still have the (potentially confusing) issue that "hold all" doesn't have quite the same effect in Cylc 8 as it did in Cylc 7 (with its pre-spawned waiting tasks). If you hold an active task it won't submit any more jobs itself (e.g. by retries) but it will still spawn downstream children (off of completed outputs) that won't be held (unless they existed already as waiting tasks in the scheduler's active window, at hold time, due to being partially satisfied or parentless).
Hold is already available from the task menu. Making it more visible from the workflow menu wouldn't make it any more accessible to you for your use case because either way you need to click the pencil symbol and edit the task pattern to *.
We have limited space in the default command list, the main use case for hold is to hold specific tasks/families/cycles, the use case for pause is to "hold" the workflow.
Closing this as it won't make holding all tasks any easier for your use case.
I disagree with your assessment.
I'm suggesting hold all, automaticaly does */*. How would that not make it quicker and easier? Pause does not hold a workflow, it stops it from doing anything, including trickling tasks through. If I pause a workflow, trigger a task, nothing happens, its pretty useless for general use and support when you want to trickle tasks through, one at a time.
I think you have a point.
But it might make more sense to allow tasks to be manually triggered when the workflow is paused. @oliver-sanders - do you recall if we had a good reason not to allow that?
(Closing as not planned as this is not known to be a common working practice, but can still be achieved on the command line)
as this is not known to be a common working practice,
Hmmm, in the early stages of developing or debugging a workflow, I'd say starting it in a "paused" state (in the general meaning of the word) and manually triggering one task at a time is actually a common and useful working practice.
But as per my question to Oliver above, the better way to do it might be to allow manual triggering in the paused state, rather than "hold-all" (which currently doesn't do what many users expect anyway, due to held active tasks still spawning and running children). I'll put an issue up for that...