Make SandboxConfig SHA256 optional to support moving runsc version.#293
Open
Jing (milantracy) wants to merge 1 commit into
Open
Make SandboxConfig SHA256 optional to support moving runsc version.#293Jing (milantracy) wants to merge 1 commit into
Jing (milantracy) wants to merge 1 commit into
Conversation
The default gvisor SandboxConfig now points at the "latest" release URL
(gs://gvisor/releases/release/latest/{arch}/runsc) instead of a pinned
nightly build. Because the binary behind "latest" changes with each
gVisor release, the SHA256 field can no longer be hardcoded in the
manifest.
When SHA256 is omitted from a SandboxConfig asset, atelet downloads the
binary and computes the hash on the fly. An in-memory URL->hash cache on
AteomHerder prevents redundant downloads within the same atelet
lifetime; restarting atelet picks up whatever "latest" currently resolves
to. The computed hash is written back into the sandboxAssetsRecord before
persisting, so checkpoint/restore manifests remain pinned to the exact
binary that created the snapshot — the moving-target semantics apply only
to new Run requests, never to restores.
Collaborator
|
I'm not sure we're OK with this. Imagine for example inexplicable CI failures due to a compatibility change. Can we not just switch to a recent weekly release instead of moving to a floating version? |
Contributor
Author
|
I can update the default template in a separate PR. can you elaborate "Imagine for example inexplicable CI failures due to a compatibility change" |
Collaborator
|
If we don't pin a version, then the runsc version changes without any commits, it won't be obvious when upgrading runsc has some regression. Test runs are not recording the version used. Ditto users with local workloads |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The default gvisor SandboxConfig now points at the "latest" release URL (gs://gvisor/releases/release/latest/{arch}/runsc) instead of a pinned nightly build. Because the binary behind "latest" changes with each gVisor release, the SHA256 field can no longer be hardcoded in the manifest.
When SHA256 is omitted from a SandboxConfig asset, atelet downloads the binary and computes the hash on the fly. An in-memory URL->hash cache on AteomHerder prevents redundant downloads within the same atelet lifetime; restarting atelet picks up whatever "latest" currently resolves to. The computed hash is written back into the sandboxAssetsRecord before persisting, so checkpoint/restore manifests remain pinned to the exact binary that created the snapshot — the moving-target semantics apply only to new Run requests, never to restores.
Fixes #284