Arvados

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?

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.

LGTM, please merge.