Idea #14870
closed
[API] Access logs from previous attempts after auto-retrying a container request
Added by Tom Clegg about 5 years ago.
Updated about 5 years ago.
Release relationship:
Auto
Description
Preserve all relevant logs in the container request's log collection, even if they span multiple containers.
Instead of just replacing the CR's entire log collection when the container's log is updated:
- Copy the container's log files into a "container ${uuid}" subdir in the container request's log collection.
- Leave any existing "container ${uuid}" subdirs alone.
- Also put a copy of the latest container's logs in the root dir of the container request's log collection. This way, existing scripts continue to work on new logs.
(Aside: This also helps in the case where the container record itself is really what's wanted, since that is included in the container's log collection. There are currently some exceptions -- e.g., a log collection isn't created at all when a container doesn't fit any instance type -- but those could be fixed.)
- Related to Feature #14706: [Crunch2] Retain references + permissions to earlier containers when retrying a container request added
- Target version changed from To Be Groomed to 2019-02-27 Sprint
- Story points set to 2.0
- Target version changed from 2019-02-27 Sprint to Arvados Future Sprints
- Target version changed from Arvados Future Sprints to 2019-03-13 Sprint
- Assigned To set to Peter Amstutz
- Status changed from New to In Progress
14870-ruby-sdk-cp-r @ 338ab239adbc259d5cd070158b4e571925b9f81b
The gist is that the ruby sdk seems to have a long standing bug where you can't copy into "." of an empty collection. It follows a different code path from the case where you are copying into a collection that already has something in it, as a result the existing test case "test_copy_root_contents_across_collections" didn't catch it.
As previously said on chat, 14870-ruby-sdk-cp-r LGTM. Thanks!
Updating the Arvados Ruby SDK dependency creates an incidental problem, #14482 tightens up manifest handling but did not update the API server dependency. That's now causing problems:
ERROR: runTest (tests.test_mount.FuseMountTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/ci-jenkins/.jenkins-slave/workspace/developer-run-tests-services-fuse/services/fuse/tests/test_mount.py", line 91, in setUp
self.api.collections().create(body={"manifest_text":cw.manifest_text()}).execute()
File "/tmp/tmp.HDfRwOWIb9/VENVDIR/local/lib/python2.7/site-packages/googleapiclient/_helpers.py", line 130, in positional_wrapper
return wrapped(*args, **kwargs)
File "/tmp/tmp.HDfRwOWIb9/VENVDIR/local/lib/python2.7/site-packages/googleapiclient/http.py", line 840, in execute
raise HttpError(resp, content, uri=self.uri)
ApiError: <HttpError 422 when requesting https://0.0.0.0:43523/arvados/v1/collections?alt=json returned "Manifest text Manifest invalid for stream 5: invalid file token "4:1:\u0001\\"">
- Status changed from In Progress to Resolved
Also available in: Atom
PDF
Updated by 
Updated by Tom Morris 
Updated by 
Updated by