Bug #10036
closed
[Crunch2] Cancelled container Queued in workbench
Added by Peter Amstutz about 8 years ago.
Updated about 8 years ago.
Assigned To:
Radhika Chippada
Release relationship:
Auto
Description
- Start a container can't run (for example, Docker failure) it bounce go between "Queued" and "Locked" states
- Hit the cancel button (set priority to 0)
- The "Locked" container goes back to "Queued"
- The container won't be run (because priority is 0) but the state continues to say "Queued" which is misleading
- Description updated (diff)
- Target version set to 2016-09-28 sprint
- Assigned To set to Radhika Chippada
Committing a new container request with priority=0 is a more direct way to arrive in this state.
A container request whose container has priority=0 and state in (Queued, Locked) should probably be described as "Ready".
(If cr.priority=0 and c.priority>0 then the request might be described as "freeloading" or "feeling lucky" ... but maybe we don't need to sort that out here.)
Showing the CR is in "Ready" state after the user clicks Cancel is still going to be confusing in my option.
In addition, it will still show different statuses based on how its associated Container is doing; Locked or Running or Failed or Success depending on the Container's current state.
Do we want to expand the Cancel button implementation to do more? For ex: remember the fact that the user clicked on Cancel in the CR's "properties" and display as "Canceled" if this is the case. And set the container_uuid to nil so that it shows as Canceled instead of what the current / ultimate state of the Container ends up being?
- Status changed from New to In Progress
Commit 5e81b09
Use "Ready" as the status label for a canceled container_request (priority 0) when it's container (container_uuid) is in Queued or Locked states as in note 5.
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
Applied in changeset arvados|commit:f088cbbb989c6fb2f0e87f226d1118cb015b06aa.
Also available in: Atom
PDF