feat: add the keep-snapshot-on-delete pod flag - #14
Merged
Conversation
A hibernatePolicy=release suspend deletes the pod to free its scheduling seat while the VM state stays claimable from the :hibernate tag. vk-cocoon cannot tell that deletion apart from a real teardown, so it GCs the node-local snapshot — and with it the only thing that would let a wake landing back on the same node skip the registry pull. This is the signal that tells them apart: the operator flags the pod just before a seat-release delete, and vk-cocoon keeps the local snapshot as a warm-wake cache. Read/Mark mirror the restore-from-hibernate pair, and PatchKeepSnapshotOnDelete follows PatchHibernateState's short-circuit. Keeping the snapshot cannot restore stale state: resolveWakeSource still verifies any local copy against the SnapshotID in the tag's config blob and discards a mismatch, so the tag stays the sole authority.
This was referenced Jul 30, 2026
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.
Why
A
hibernatePolicy: releasesuspend deletes the pod to free its scheduling seat, while the VM state stays claimable from the:hibernateregistry tag. But vk-cocoon'sDeletePodcannot tell that deletion apart from a real teardown, so it GCs the node-local snapshot — and with it the only thing that would let a wake landing back on the same node skip the registry pull.The wake path is otherwise already local-first:
resolveWakeSourceprefers a local snapshot and only pulls on a miss, andcleanupWakeImportexplicitly keeps the local copy "live for the next wake".retainis fast today precisely because its pod is never deleted, so its snapshot is never GC'd. This flag givesreleasethe same fast path without holding the seat.What
AnnotationKeepSnapshotOnDelete=vm.cocoonstack.io/keep-snapshot-on-delete, plusReadKeepSnapshotOnDelete/MarkKeepSnapshotOnDeletemirroring therestore-from-hibernatepair.PatchKeepSnapshotOnDelete, followingPatchHibernateState's short-circuit shape.Additive only — nothing reads the flag until the operator and vk-cocoon PRs land.
Safety
Keeping the snapshot cannot resurrect stale state.
verifyLocalSnapshotcompares the local snapshot's ID against theSnapshotIDin the hibernate tag's config blob and discards any mismatch; a missing tag is judged stale; an unreachable registry fails closed. The tag remains the sole authority, and the local copy is strictly a cache keyed by it.Follow-up (not in this PR)
Nothing reclaims a kept snapshot today — vk's orphan policy covers VMs, not snapshots. Before this ships, node-level
cocoon gc --snapshot --snapshot-size/-ageneeds to bound the cache, and vk's storage allocatable (read once at startup) needs to stop hiding it from the scheduler. Otherwise this trades silent disk oversubscription for memory oversubscription.Test
go build ./...,go test ./...,make lint(linux + darwin) all green.