-
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
cylc dependencies: report prerequisites that cannot be met #1585
Comments
A distant relative to this issue is #1286. |
Of relevence, looks like Hilary suggested something similar in #1286 (comment) on that thread:
|
I'll look into this on my return from holiday. |
It seems to me, that if a suite does not rely on ignoring pre-initial triggers - #1603 - any combination of restart and warm start will work correctly, except when a manual intervention results in a task whose dependencies can't be met (e.g. one or more tasks was |
Yeah #1603 would address most of this. The remaining situation would be where a restart or reload introduces a new task and dependencies on it but the operator forgets/doesn't know to insert the new task into the pool - #774 should prevent this though if it's possible. The other case would be where a new dependency on an existing task is added but the task has already cycled out of the pool prior to the reload. |
With the introduction of stalled handlers in #1848 I think a number of the problems that result in a need for this are addressed i.e. if you're worried about something getting stuck you can pop in a stalled handler to fire off it it does, at which point you can then go in and inspect things for yourself. I'm sort of struggling how we could do this in a non compute intensive way. Perhaps, something that could be tagged on to the new stalled handler functionality is an inspection of (non clock trigger dependent) tasks that are still in a waiting state and reporting any unmet prereqs in the error log as warnings. Maybe something like this would be the thing to do:
resulting in:
@hjoliver - thoughts? |
I think we should just report unmet prerequisites on stalled regardless. There is no need to do any computation, because by definition all waiting tasks stall when the suite stalls. |
Recently we've seen a number of situations where combinations of suite changes with warm starts and restarts have meant that suites have stalled due to prerequisites that cannot be met given the contents of the task pool i.e. missing tasks.
It would be useful to be able to highlight these dependencies in some way.
One suggestion, based on a user request, would be to have a command line tool that listed all the currently unfulfillable dependencies for tasks in the pool. There should also be some form of highlighting in the gui via the view prerequisites dialog.
What may prove difficult is avoiding false positives in the returned values.
For example, it's easy enough to inspect a task pool in this simple situation:
as all we have to do is look in the task pool at bar, identify that it's looking for foo at -PT6H, and check the task pool for its presence.
However, this sort of thing is slightly more difficult:
as baz will be in the pool before foo at -PT6H relative to baz is added.
Even more complex, we've seen suites where there is graphing of this form:
where identically named tasks are being run but in the triggering of different models grouped together in a suite. In this case, this makes it even more difficult as simply checking for presence of foo in the task pool at an earlier cyclepoint would fail to initially highlight a problem until cycling had got sufficiently far on.
Finally, there is also this sort of situation:
where
final_task
could be hanging around for a long period without its immediate requirement being meetable. Any tracking back of dependencies could be potentially expensive here.In some respects this relates to #1540 though have seen it more recently with restarts following a warm start or where a restart has resulted in changed graphing.
The text was updated successfully, but these errors were encountered: