Story #12917

Users should be able to see if a container failed from the container_request method

Added by Bryan Cosca about 1 year ago. Updated 9 months ago.

Status:
New
Priority:
Normal
Assigned To:
-
Category:
-
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
(Total: 0.00 h)
Story points:
2.0

Description

Users should be able to see the exit code or state=[“Queued”, “Locked”, “Running”, “Cancelled” and “Complete”] from the container_request api method, rather than having to go another layer deeper to the container api method.

Proposed solution

Add a general "include" option to the index (list) method.

include=container includes the contents of the record associated with container_uuid

Can only be used on fields ending in _uuid

A query like this would return:

?include=container

{
  "items": [
    {
      "kind": "arvados#container_request",
      "uuid": "abc-123",
      "container_uuid": "xyz-123" 
      ...
    }
  ],
  "includes": [
    {
      "uuid": "xyz-123",
      "state": "Completed",
      "exit_code": 0,
      ...
    }
  ]
}

Initially we will only adopt this syntax but initially limiting the implementation to only container requests.

If used for anything other than include=container on container_request it should return an API error.

Discussion points for future:

  • selecting fields in the includes
  • Permission enforcement. Permission to read a container is based on permission to read the container_request, but this is not true generally. For example, permission to read a container request doesn't grant permission to read output_uuid.
  • Straightforward to set up a join when the _uuid field points to exactly one record type (only collections, only containers, etc) but more complex when it can point to multiple (owner_uuid, head/tail_uuid on links)

Subtasks

Task #13355: ReviewNewTom Clegg


Related issues

Related to Arvados - Story #13327: [Workbench] Use new API container_request?include=containerNew

Has duplicate Arvados - Story #13145: Include container status & exit code in container request responseDuplicate

History

#2 Updated by Tom Morris 11 months ago

  • Target version set to To Be Groomed

#3 Updated by Peter Amstutz 11 months ago

Suggest adding virtual fields container_state and container_exit_code which have the value of the corresponding fields of the record with container_uuid, or null if no container is assigned.

Alternately, we could add a query parameter which specifies that we want the entire container record embedded in the response.

#4 Updated by Tom Morris 10 months ago

  • Subject changed from Users should be able to see if a CR failed from the CR method to Users should be able to see if a container failed from the container_request method

#5 Updated by Tom Clegg 10 months ago

IMO, these aren't container_request fields so they shouldn't appear as container_request fields.

Suggest we support an "include container record" flag in container_requests#index and #show requests, and return the whole container record.

Since we're not (yet?) using jsonapi, we need to choose a response format for this. We should use something that can extend to other similar situations, like "include created_by_user record".

#6 Updated by Peter Amstutz 10 months ago

  • Description updated (diff)

#7 Updated by Peter Amstutz 10 months ago

  • Description updated (diff)

#9 Updated by Peter Amstutz 10 months ago

  • Description updated (diff)

#10 Updated by Peter Amstutz 10 months ago

  • Description updated (diff)

#11 Updated by Peter Amstutz 10 months ago

  • Description updated (diff)

#12 Updated by Tom Morris 10 months ago

  • Related to Story #13327: [Workbench] Use new API container_request?include=container added

#13 Updated by Peter Amstutz 10 months ago

  • Description updated (diff)
  • Story points set to 2.0

#14 Updated by Peter Amstutz 10 months ago

Just one thought, we have wandered a little bit from the original goal of making the API easier for getting container status from container_request. Returing a separate "includes" section takes a similar amount of Python code to interpret as the current approach that requires making a second API call. Embedding the record in each item so that one can can write items0[container][state] is much simpler for the user (ie Bryan).

That said, "includes" is a more general solution that is better suited for other use cases like optimizing Workbench queries and so probably still the one we go with.

#15 Updated by Tom Clegg 10 months ago

Perhaps the client library could offer a "join response items" convenience function that assigns includes[x] to items[y][f] for all items[y][f+'_uuid']==includes[x]['uuid']...?

#16 Updated by Tom Morris 9 months ago

  • Target version changed from To Be Groomed to 2018-04-25 Sprint

#17 Updated by Tom Morris 9 months ago

  • Assigned To set to Peter Amstutz

#18 Updated by Peter Amstutz 9 months ago

  • Has duplicate Story #13145: Include container status & exit code in container request response added

#20 Updated by Peter Amstutz 9 months ago

  • Target version changed from 2018-04-25 Sprint to 2018-05-09 Sprint

#21 Updated by Tom Morris 9 months ago

  • Assigned To deleted (Peter Amstutz)
  • Target version changed from 2018-05-09 Sprint to Arvados Future Sprints

Also available in: Atom PDF