[Crunch2] Cancelled container Queued in workbench
- 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
#4 Updated by Tom Clegg over 4 years ago
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.)
#5 Updated by Radhika Chippada over 4 years ago
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?