Feature #12917
Updated by Peter Amstutz about 7 years ago
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. h2. Proposed solution Add a general "include" embedding option: include=["container"] includes * embed=["container_uuid"] embeds the contents of the record associated with container_uuid * embed_select=["state", "exit_code"] limits the fields of the embedded record to just the selected ones Can only be used on fields ending in _uuid A query like this would return: ?include=["container"] ?embed=["container_uuid"]&embed_select=["state", "exit_code"] <pre> { "items": { [ { "kind": "arvados#container_request", "uuid": "abc-123", "container_uuid": "xyz-123" ... } ] "xyz-123", }, "includes": [ "container": { { "uuid": "xyz-123", "state": "Completed", "exit_code": 0, 0 }, ... } ] } </pre> Initially we will only adopt this syntax but initially limiting the implementation to only container requests. Discussion points for future: points: * 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) * Should the field be named by stripping the _uuid? Other ideas: "embedded_container", "container_uuid_embed" It might be worth adopting this syntax but initially limiting the implementation to only container requests.