Arvados

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.

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".

http://jsonapi.org/format/#fetching-includes

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 items⁰[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.

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']...?

Again speaking privately here. This seems important. Workbenches are slow because of small API issues like this one. [uuid, in, [...]] filter to retrieve corresponding containers seems always a bit on the slow side. Thank you in advance.

12917-group-contents-include-container @ 8a47094aa45b6352e71141c39f69c28c7f38b08c -- developer-run-tests: #4239

still needs documentation update.

12917-group-contents-include-container @ 9bda36e2c94aefc6cb05763e453ad4afdaa6199d -- developer-run-tests: #4243

• All agreed upon points are implemented / addressed.
  • include=container_uuid works similarly to owner_uuid
  • include=["container_uuid","owner_uuid"] allows including both owner and container
• Anything not implemented (discovered or discussed during work) has a follow-up story.
  • I did not implement selecting fields like "containers.uuid". The description says this should work similarly to group contents, and it doesn't work for group contents. We could implement this, but I think it should be a separate story rather than blocking this one. For now, it works to select bare attributes -- "state" selects the state attribute for object types that have one, and the field selection applies to both the main items and the included items.
• Code is tested and passing, both automated and manual, what manual testing was done is described
  • ✅ automated
• Documentation has been updated.
  • ✅
• Behaves appropriately at the intended scale (describe intended scale).
  • More efficient than getting the same information with multiple API calls.
• Considered backwards and forwards compatibility issues between client and server.
  • If a controller is upgraded before its backend railsapi, then ?include=owner_uuid requests will fail until railsapi is upgraded. The documented upgrade procedure upgrades both of those packages while arvados services are stopped, so this shouldn't come up.
• Follows our coding standards and GUI style guidelines.
  • ✅

This lgtm!