Container status / outcome reporting¶

Given that some container processes (like arvados-cwl-runner) are aware of Arvados, and API credentials are already made available inside the container, such processes could update their own container records at runtime with information like

• Progress info (with more detail than accommodated by the [0,1] range accepted by the "progress" field)
• Error summary like "step {foo} failed" or "error in workflow description: ..."
• "Container will fail" flag

The "container will fail" flag, in particular, could be used in a container request's "filters" field to avoid reusing workflow-runner containers that are already known to be in an error state but haven't yet exited non-zero.

If arvados-cwl-runner establishes some conventions, Workbench and other clients can pass this info on to users when available.

arvados-cwl-runner, when invoked from CLI, can use the "filters" field in its container request (see Containers API) to avoid reusing arvados-cwl-runner containers with a non-empty "error" value here.

Possible examples¶

{
  "error": "step foobar failed: waz not found" 
}

{
  "status": "waiting for jobs to finish",
  "jobsComplete": 7,
  "jobsWaiting": 3,
  "jobsFailed": 0
}

{
  "status": "reading inputs" 
}

System components like crunch-run and crunch-dispatch-slurm might also use this field (or a similar separate system-only field) to report more status/progress detail.

{
  "status": "loading docker image" 
}

{
  "status": "flushing logs to Keep" 
}