Feature #20319
closed
Move containers/{uuid}/log/ to container_requests/{uuid}/log/
Files
Updated by Tom Clegg almost 2 years ago
- Related to Idea #16442: Scalable + reliable container logging added
Updated by Tom Clegg almost 2 years ago
- Related to Feature #19889: access current container logs at /arvados/v1/containers/{uuid}/log/{filename} added
Updated by Tom Clegg almost 2 years ago
- Target version changed from Development 2023-04-12 sprint to Development 2023-04-26 sprint
Updated by Tom Clegg almost 2 years ago
in progress...
20319-container-request-logs @ 5cc1710b57f98905469225c68d975ad2e3e7e56d -- developer-run-tests: #3614
Updated by Tom Clegg almost 2 years ago
This move is convenient in that underneath /arvados/v1/$container_request_uuid/log/ we can use the same "subdirectory per container" layout that we use in the container request log collection.
However this does leave us with a couple of complications.
First: The CR log collection has subdirectories named"log for container $c_uuid", not just $c_uuid. We could:
- Make the new API
/arvados/v1/$container_request_uuid/log/log for $container_uuid/, which seems a bit awkward - Change the container request log layout so the subdirectory is just called
$c_uuid, which is a little less human-friendly and would probably break some scripts - Make the new API
/arvados/v1/$container_request_uuid/log/$container_uuid/, and leave the CR collection layout alone, which is potentially a little confusing / more complicated for clients that use both this API and the regular WebDAV endpoint
For now I've done the last option. One reason is that I don't think the layout can ever match perfectly anyway: the top-level log files in the CR log collection ("logs for the last container that ran") don't really have a counterpart here. (If we offered "logs for the current/last container" at the top level, I think we would just be inviting weird behavior when a client doesn't notice the files shrinking/rewriting during a cancel/retry cycle.)
Second: Producing a full directory listing at.../log/ is complicated by the fact that part of the tree comes from the container gateway (the current container) and the rest comes from keep-web. Currently I've avoided this by noting in the docs that the current (running) container's log subdir doesn't show up in directory listings. But we could:
- make it show up in a depth=1 traversal (intercept PROPFIND and serve it in controller by getting the log collection, splicing an empty dir into it, and putting a webdav handler on that)
- make its content show up in a depth>1 traversal (as above, but also fetch a dir tree from the container gateway, and splice that on)
Both options (especially the second) seem like a lot of trouble, maybe more trouble than it's worth. Practically speaking, "get container_uuid from the container_request record and stick that in the path" doesn't seem all that painful. After all, clients already need special behavior for the running container's logs because they're getting updated on the fly.
20319-container-request-logs @ 92bf76b1077282126b8a1c446458c6618a36e5d5 -- developer-run-tests: #3615
retry keep-balance developer-run-tests-remainder: #3801
Updated by Tom Clegg almost 2 years ago
- File 20319-doc.png 20319-doc.png added
snapshot of doc update in this branch:
Updated by
Updated by Tom Clegg almost 2 years ago
- % Done changed from 0 to 100
- Status changed from In Progress to Resolved
Applied in changeset arvados|c3b8da6f91b95570dde6cbf814b270dc3763f7f7.
Updated by