Update graph view after suite shutdown

[cylc]

Update graph view after suite shutdown

I think we'll probably have to blank the canvas for a stopped suite unless we delay suite shut down long enough for any connected control GUIs to get in a final update request.

[benfitzpatrick]

At the moment it seems to be doing this - however, it actually seems not to be desirable! If a task fails and the suite shuts down (admittedly this shutdown option is not one everyone takes), the information disappears. Equally if the suite shuts down because it completed, the information disappears, and it's difficult to tell the difference between the two. Turning this on its head, should we allow gcylc to recover the last state of a suite after shutdown?

Yes, I made the change (to blank the canvas if the GUI could no longer connect to the suite) when I put in the recent remote control changes. For gcylc to get the final pre-shutdown state it would have to spawn an ssh process (it could be a remote suite) to parse the suite state dump file - is this what you're suggesting?

By the way, there is no "shut down if a task fails" option - perhaps you've implemented this at the Met Office as a task event hook script?

Maybe a simpler way to handle this would be an option (perhaps the default) to never shut a suite down automatically, so the final state would always be visible (via the normal Pyro mechanism) until the operator shuts the suite down manually ...

[dpmatthews]

You're right that we've implemented the option to shut down a suite if a task fails via a hook script. For simple suites which, for instance, just compile & then run a model this seems the most sensible thing to do since the user will almost always want to fix the problem & then re-run the suite.

The problem with leaving a completed suite running is how do you ensure that the user shuts it down? We'd need a way to ensure that we didn't end up with lots of forgotten suites cluttering up our systems.

The best alternative we've thought of is a summary of the final state dump which, as you say, it would have to retrieve via ssh if necessary. Does this sound a sensible idea? One advantage might be that you would also see what state a suite is in before you do a restart.

Yes, that sounds eminently sensible. The one complication I can think of is that the state dump file contains less information than the suite state summary structure accessed by the control GUIs. The best way to handle this may be to populate the same state summary structure from the state dump, with missing information defaulting to something sensible.

[benfitzpatrick]

Alternatively, we could get by without updating the GUI views by just recovering the 'number of failed tasks' information from the state and displaying it in the status bar or a dialog, or something. This would tell the user what they really need to know about the last run of their suite.

Ben, that sounds good, at least as an interim measure.

[benfitzpatrick]

It might be quite nice to integrate the information into cylc dump as well - it's a near perfect match with the state file.

[benfitzpatrick]

Addressed for now by the above 'quick fix' in 4b39ed3 , and a0e8bf8

[benfitzpatrick]

I think this is sorted now.