Bug #10036

[Crunch2] Cancelled container Queued in workbench

Added by Peter Amstutz about 5 years ago. Updated almost 5 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Radhika Chippada
Category:
-
Target version:
Start date:
09/22/2016
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Story points:
-
Release:
Release relationship:
Auto

Description

  1. Start a container can't run (for example, Docker failure) it bounce go between "Queued" and "Locked" states
  2. Hit the cancel button (set priority to 0)
  3. The "Locked" container goes back to "Queued"
  4. The container won't be run (because priority is 0) but the state continues to say "Queued" which is misleading

Subtasks

Task #10058: Review branch 10036-canceled-container-stateResolvedRadhika Chippada

Associated revisions

Revision f088cbbb
Added by Radhika Chippada almost 5 years ago

closes #10036
Merge branch '10036-canceled-container-state'

History

#1 Updated by Peter Amstutz about 5 years ago

  • Description updated (diff)

#2 Updated by Tom Morris about 5 years ago

  • Target version set to 2016-09-28 sprint

#3 Updated by Radhika Chippada about 5 years ago

  • Assigned To set to Radhika Chippada

#4 Updated by Tom Clegg about 5 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 about 5 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?

#6 Updated by Radhika Chippada almost 5 years ago

  • Status changed from New to In Progress

#7 Updated by Radhika Chippada almost 5 years ago

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.

#8 Updated by Lucas Di Pentima almost 5 years ago

LGTM, please merge.

#9 Updated by Radhika Chippada almost 5 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

Applied in changeset arvados|commit:f088cbbb989c6fb2f0e87f226d1118cb015b06aa.

Also available in: Atom PDF