-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Held running tasks: delay spawning or hold children? #5696
Comments
Suggest merging this with:
Which should all be "solved" together if we agree to an approach, rather than debate each aspect of each command on a command by command basis. Suggest changing issue title to: "task globing beyond n=0 window" |
Maybe, if you can convince me of the need for a more general approach. I mean, what commands other than
|
To name just three!
It is and it isn't. These commands use the same code for globing tasks and handing the situation where tasks are not found. Unless we want to implement this code separately for each command (and have a confusing CLI) and changing the implementation (and documentation which is also common), then adapting one will adapt all. But also, if |
With spawn-on-demand there are often no waiting tasks in the pool, which makes "hold" (by glob to match in the pool) pretty
much useless. Holding a task that is already running has no effect (except to hold back any retries).
If
b
is running and I want to pause execution of this branch without pausing the whole workflow, I currently have to individually hold all members ofFAM
(family names and globs currently only match in the task pool).Making hold work the way that users no doubt expect - i.e., to be able to easily hold parts of a running workflow without pausing the whole thing - should IMO be part of our current push to get intervention capability nailed down in Cylc 8.
Option A
Held running tasks should pass the held "attribute" on to children.
If I hold
b
, members ofFAM
will be spawned whenb
succeeds, but they will be held.Pros:
Cons:
Option B
Held running tasks should not spawn children until released.
If I hold
b
, it will remain in the pool as succeed and held, until released, at which point it will spawnFAM
.Pros:
Cons:
--wait
flow trigger option)I think I prefer Option B. It is more intuitive and has one less "con" by my count.
The text was updated successfully, but these errors were encountered: