As an operator, I want to be able to monitor the status of a given Workflow Execution from a workflow Dashboard

[mike-gangl]

• High level workflow status can be viewed (pending, in progress, completed, failed)
• Workflow steps can be statused
• includes workflow execution details (submitter, time, labels)

Will most likely rely on HySDS UIs for short-term visibility; We should also explore Airflow and see if that interface is better suited for Operators, Algorithm Developers

UPDATE:

1. SPS will create these tasks in the CWL to update job status. we will focus on the first and last boxes, but can add more “easily” (hah!). These should be a part of the application pakacge initially, but we will also want to think of how we can arbitrarily wrap any task (e.g. CMR requests, data catalog requests).

2. The orange boxes (below) will not hit an https service directly, but will send SNS messages, this is for scalability reasons (think of all the messages that would be sent to a single endpoint for a large reprocessing job with millions of jobs

3. The SNS message will be a bit of metadata, probably consisting of jobID, status, labels, timestamp.. other stuff? products/outputs (maybe after stage-out) (see below)

4. on the other end, something will be listening to these messages (and queuing them…) and writing them to a catalog (database, elastic search, whatever) for querying (maybe query by jobid, query by label, query by “parent job”) to name 3 that i think are helpful

5. we need an interface for searching that endpoint- it can be a restful API or it can be against elastic search directly- there are pros and cons for this.SPS will create tasks / code that will be inserted into the

Required Metadata

• jobID
• parent JobID (?)
• job status
• label(s)
• create time
• completion time
• job submitter
• current step (?) / last step statused (?)
• inputs (references?)
• outputs (references?)

Endpoint Functions

• register job
• update job
• list jobs

Removed from AC:

• list jobs with filter: label
• list jobs with filter: submitter
• list jobs with filter: an updates within timerange (Start/stop)
• list jobs by parent job ID

[rtapella]

UI Design stories:

https://docs.google.com/document/d/1-3WEJqwPuLpqVqpnS-2EcnMC6P3KgxUE35xs_FmHADY/edit#heading=h.754zq8lye6l2

[rtapella]

v1. single workflow (black box) v2. single workflows (per-step) v3. batch workflows

[rtapella]

WPS-T part: https://github.com/orgs/unity-sds/projects/7/views/1?filterQuery=label%3AEpic+status&pane=issue&itemId=18698723

https://github.com/orgs/unity-sds/projects/7/views/1?filterQuery=label%3AEpic+status&pane=issue&itemId=18698960

[rtapella]

WPS-T errors: https://github.com/orgs/unity-sds/projects/7?pane=issue&itemId=18699536

[rtapella]

SPS work: Also see https://github.com/unity-sds/unity-sps-prototype/issues/133

and https://github.com/unity-sds/unity-sps-prototype/issues/134

[mike-gangl]

@rtapella this epic is fine, but i think we need epics for the "submission" portion as well, that is, for the SounderSIPS example, a (user-friendly) way of specifying the date, output collection, etc

[mike-gangl]

per some of our conversations, we can keep this feature/epic open, but we may want to allow for HySDS dashboards in the near terms; also investigate airflow and see how that works for the Operators.

There is still an on-going "unified experience" if we rely on implementation level dashboards.

[rtapella]

I think the list of metadata you have is a good starting point.

Ideally a table view would have customizable columns. Even if it's "bullet-listed" into a list of jobs with metadata you could customize which bits get displayed in the main scrollable list vs. in a "details" view.

On the "create time" I think there's a distinction between when you submit a batch and when a particular job starts being executed. So it may turn in to submit-time, start-time, end-time for a particular job (and even task). Duration is often more interesting to ppl than a specific start/stop as it's more of an indicator of issues.

It'd be nice to be able to filter on any column individually or any column globally. Info that is part of a controlled vocabulary (e.g. status) should have a dropdown type of list for selection.

A link to stdout/log-files is also important, particularly for failed jobs.

I'm not sure if job ID and parent job ID are related to workflows here. But to make it explicit:

• You should be able to get aggregated stats across everything running in the system
• You should be able to get aggregated stats for a particular batch of jobs at either the workflow level or the task-level (steps in the workflow)
• For a job, you should be able to see progress/status along each step of a workflow
• You should be able to see the jobs that other team members are running, or filter it to just stuff you are running (or have run)

[rtapella]

For now, stderr from WPS directly. No links to logs or anything like that.

[rtapella]

Job submitter from https://github.com/unity-sds/unity-sps-prototype/issues/137

[anilnatha]

Summary of initial codebase work:

• Created boilerplate React app using Vite
• Integration of UI Router
• Preliminary addition of a navbar based on Figma design
• Addition of AG Grid to mock up Job Monitor Data Grid with stubbed in data

Items discussed with @rtapella and @AaronPlave yesterday:

• With the PR for navbar and related components completed for react-stellar, can integrate those into the Unity UI in place of the preliminary navbar
• Need to integrate authentication to enable calls to SPS for job monitoring
• Implement Job Detail Panel
• Other under the hood enhancements to facilitate state management (needed to manage user state and possibly other data).

[rtapella]

@LucaCinquini per-step workflow status will not happen until the JobsDB/EMS/thing is built, correct?

[LucaCinquini]

Maybe even after that :( With the first version of the jobs database (this release), you will be able to query for all workflows at once, but investigating each step is still not supported. We need to discuss how this could be implemented with the current architecture.

[rtapella]

act upon jobs in the list: https://github.com/unity-sds/unity-jobs-ui/issues/20

[rtapella]

outsource to Airflow. same requirements https://github.com/unity-sds/unity-project-management/issues/81

[rtapella]

this was never Closed, just marked Done