Create a user dashboard

[kinow]

Could overlap a bit with current work related to Analytics. Could also display per suite/task metrics, etc. Which components to be used in this dashboard?

Raised by @matthewrmshin during the Exeter meetup 2019/06.

[hjoliver]

The dashboard can probably be quite minimal initially, with more info added post cylc-8.0.0.

[matthewrmshin]

Some ideas of what to display:

• General health of the workflows the user is running. Information that tells users to take action and/or warn users of IT issues. E.g. Number of failed tasks/jobs and a link to a list of them. A plot of top queuing times for jobs in submitted state. Response time of any running servers. Number of active tasks/jobs in all workflows.
• Resource usage. Information that enable users to better plan resource usage. E.g.: Plot of tasks/jobs using the most computing resources (per cluster). Plot of number of active tasks against time (i.e. when are the busiest times during the day of your workflows).
• Links to relevant site status pages and docs?

[hjoliver]

First step (easy):

• Links to docs.

I guess we need something configurable, for:

• Links to relevant site status pages.

[kinow]

Would users be able to customize their dashboards, or should we leave it for another release post cylc8.0? I guess it depends on the other issue for user preferences as well.

[hjoliver]

I suggest:

• 8.0.0: just Cylc logo and doc links, maybe with some site configurable links (e.g. to local system status info)
• post 8.0.0 - OR earlier IF we have time after doing the critical path stuff - useful analytics such as suggested by @matthewrmshin
• and not necessary to allow user-customization until we have multiple dashboard content options to choose between?

(it might be a bit of work to do the analytics)

[kinow]

+1 Sounds good. Incremental and small tasks, easier to see progress and close this ticket with a few follow ups for next releases.

[sadielbartholomew]

Just a thought on your suggestion, @hjoliver:

I suggest:

8.0.0: just Cylc logo and doc links, maybe with some site configurable links (e.g. to local system status info)
post 8.0.0 - OR earlier IF we have time after doing the critical path stuff - useful analytics

@matthewrmshin mentioned to me in conversion (along the lines of this, though of course only Matt can describe his own ideas & vision, so he's the one to hear from), & I agree, that displaying some very basic analytics, namely stats that we already have accessible from the data we currently fetch, such as:

• the total number of suites the user has running (perhaps broken down by suite state);
• the times they have been running for;
• the number of tasks in each suite which are in important states such as failed,

etc. would not be difficult to add in for 8.0.0, & more useful than just the links on their own.

More fancy analytics e.g. plots, charts etc. could indeed be trickier or time-consuming, though, so I agree otherwise. There is a lot of potential for very sophisticated & useful components on the analytics side for the dashboard, & it is the first thing users will see when they open the UI, so I certainly wouldn't want us to rush the "final" dashboard implementation.

[hjoliver]

@sadielbartholomew - agreed, if we can add that stuff easily enough, let's do it.

[oliver-sanders]

Couple of quick things we may want to be accessible from the Dashboard:

• User settings
  • Application theme
  • Job icon theme
  • etc
• Cylc Hub
  • Link to hub
  • Stop Server?
• Help
  • Documentation
  • Suite Design Guide
  • Quickstart (in-app tour of the Cylc GUI)?

See also design document which as an illustrative example has the number of workflows in each state (x running, y held, z stopped) and workflow events of severity warning or higher (may be more interesting to implement).

[kinow]

I think we can implement the initial version of the design document. Leaving these links in the dashboard, instead of in the menu, would also tidy it up a bit.

Then later we can create other issues about customization of dashboards, and other improvements.

[sadielbartholomew]

Then later we can create other issues about customization of dashboards, and other improvements.

I'm hoping to create a largely self-contained store of ideas & of user feedback & requests regarding suite & task analytics, since there is a lot of information building up in that respect that we should collate, & I cannot see a dedicated Issue for that in any repo. This Issue seems to have converged on the nature of the minimal 8.0.0 dashboard, so I am going to open a new one accordingly for the full-featured "ideal future" dashboard. Update: actually, #57 will do, as that is essentially analytics only, it just needs a wider scope, so I might edit the title & note as such in a comment there. Saying that, it is not clear whether we would want all analytics aspects to be on the dashboard, we could have a whole separate page...

This particular Issue can then pertain to the dashboard for 8.0.0, is that okay @kinow? The question here then becomes what more we want in the dashboard than has been implemented in #149. Is there anything, say in Matt's suggestions #94 (comment), that we think should go in now? The low hanging fruit, perhaps?

[oliver-sanders]

store of ideas & of user feedback & requests regarding suite & task analytics,

We do have a plan to add an "analytics view" (suite+task info), this would be a per-suite view alongside graph, dot, etc. There used to be an issue on Cylc Flow for this, (the cylc report-timings command was linked to this), there should be a new issue for this.

[matthewrmshin]

For task analytics, I believe users would probably want per-suite as well as a view for groups of suites. E.g. they may want to analyse all tasks running a similar model with different configurations in a set of trials. Or a production user may want to know how much HPC node-hours they have consumed in a time series. Or the failure rate of the archiving tasks across all suites. Etc.

[kinow]

@sadielbartholomew all good for me. I thought this would be one of those issues that take a while to close, and have multiple PR's (e.g. #149).

[oliver-sanders]

they may want to analyse all tasks running a similar model with different configurations in a set of trials

Hmm, that could be interesting. Hierarchical suites give us a convenient landing page to display analytics for a group but I think a rigid hierarchy probably won't suffice for this.