Make SandboxConfig SHA256 optional to support moving runsc version.#293
Make SandboxConfig SHA256 optional to support moving runsc version.#293Jing (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.
|
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? |
|
I can update the default template in a separate PR. can you elaborate "Imagine for example inexplicable CI failures due to a compatibility change" |
|
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 |
+1 to what Benjamin Elder (@BenTheElder) said, we cannot point to latest, since what if latest will be broken. We always supposed to pointed out to the well tested version. |
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