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"
}
Updated by Tom Clegg about 6 years ago · 1 revisions