Skip to content

feat(clone): reap the internal snapshot a clone took on its source - #200

Open
Andrei Kvapil (kvaps) wants to merge 1 commit into
fix/csi-clone-and-restore-idempotencyfrom
feat/clone-snapshot-reap
Open

Andrei Kvapil (kvaps) wants to merge 1 commit into
fix/csi-clone-and-restore-idempotencyfrom
feat/clone-snapshot-reap

Conversation

@kvaps

@kvaps Andrei Kvapil (kvaps) commented Oct 7, 2026 •

Copy link
Copy Markdown
Member

Stacked on #190.

A clone of a source with volumes takes clone-<target> on the source, and nothing ever deleted it, so once a clone existed the source could never be deleted through the API, which refuses a definition that has snapshots. rd d of a clone now reaps that snapshot, on both the REST and the CLI door.

Ownership is a prop the clone path stamps, never the name, so an operator's snapshot called clone-<target> is never touched. A snapshot another definition was restored from is kept. The reap marks the snapshot, lists dependents past the cache, and only then deletes; a restore reads its snapshot back past the cache once its definition exists and withdraws on a live mark, on a delete in flight, or on a snapshot that is gone. Whichever of the list and the create comes second sees the other. The store now surfaces DELETE on a snapshot a satellite finalizer still holds, and the snapshot list no longer stamps SUCCESSFUL beside it. A later rd d of the source names what is left and why, including a snapshot whose delete is already in flight, which only needs a retry.

A restore that withdraws takes its definition back through the rollback handshake, so one a retry adopted is left to it. A withdrawal caused only by a reap's mark answers a retryable 409; a snapshot that is gone answers 404. A kept or failed reap is a warning in the answer to the delete.

@coderabbitai

coderabbitai Bot commented Oct 7, 2026 •

Copy link
Copy Markdown

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

Run configuration
  • Source mode: Auto
  • Repository: Unavailable
  • Branch: Unavailable
  • File: No configuration file from this repository applied
  • Commit: Unavailable
  • Layers: defaults
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: 10e0263e-94ce-49f9-8725-51f20ff1cd78

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@kvaps
Andrei Kvapil (kvaps) force-pushed the fix/csi-clone-and-restore-idempotency branch from 47acc58 to a4f876d Compare October 8, 2026 03:38
@kvaps
Andrei Kvapil (kvaps) force-pushed the feat/clone-snapshot-reap branch 2 times, most recently from 3275ac7 to f63a9f2 Compare October 8, 2026 08:43
@kvaps
Andrei Kvapil (kvaps) force-pushed the fix/csi-clone-and-restore-idempotency branch 2 times, most recently from 4ab3ffd to 5b23086 Compare October 8, 2026 12:28
@kvaps
Andrei Kvapil (kvaps) force-pushed the fix/csi-clone-and-restore-idempotency branch from 5b23086 to 597e7c8 Compare October 8, 2026 17:58
@kvaps
Andrei Kvapil (kvaps) force-pushed the fix/csi-clone-and-restore-idempotency branch from 597e7c8 to 3e5eede Compare October 8, 2026 20:15
@kvaps
Andrei Kvapil (kvaps) force-pushed the fix/csi-clone-and-restore-idempotency branch from 3e5eede to d77d76c Compare October 9, 2026 16:54
@kvaps
Andrei Kvapil (kvaps) force-pushed the fix/csi-clone-and-restore-idempotency branch from d77d76c to 7a940cd Compare October 9, 2026 19:50
@kvaps
Andrei Kvapil (kvaps) force-pushed the fix/csi-clone-and-restore-idempotency branch from 7a940cd to 8771682 Compare October 12, 2026 22:51
@kvaps
Andrei Kvapil (kvaps) force-pushed the fix/csi-clone-and-restore-idempotency branch 4 times, most recently from 0473bdc to 53929ba Compare October 23, 2026 07:21
@kvaps
Andrei Kvapil (kvaps) force-pushed the feat/clone-snapshot-reap branch 2 times, most recently from 1994457 to bbc42a2 Compare October 23, 2026 20:30
@kvaps
Andrei Kvapil (kvaps) marked this pull request as ready for review October 23, 2026 20:31
A clone of a source with volumes takes `clone-<target>` on the source
and restores from it, and nothing ever deleted that snapshot. Deleting
the clone left it behind, and the source could then never be deleted
again through the API, which refuses a definition that has snapshots.
Every CSI clone goes through this path.

`rd d` of a clone now reaps that snapshot, on both the REST and the
CLI door. Ownership is a prop the clone path stamps on the snapshot,
never its name, so an operator's snapshot called `clone-<target>` is
never touched.

The snapshot is visible in `s l`, so another definition can have been
restored from it, and that definition keeps reading it: new replicas
are pinned to its nodes and restored from it by name. A dependent
appears in two steps, the snapshot read and the definition create, so
no list on the reap's side alone can see one between them. The reap
marks the snapshot, then lists dependents past the cache, and only
then deletes; a restore creates its definition, then reads the
snapshot back past the cache and withdraws on a live mark, on a
snapshot whose delete is in flight, or on one that is gone. Whichever
of the list and the create comes second sees the other. A snapshot
the reap keeps has its own mark taken off again, and a mark another
reap wrote since is left alone.

A withdrawal takes the definition the restore created back through
the rollback, with its handshake: one a retry of the same restore
adopted in the meantime is left to that retry. A withdrawal caused
only by a reap's mark answers a retryable 409, since the reap may yet
keep the snapshot; a snapshot that is gone, or whose delete was
issued, answers 404 as before. The CLI checks the snapshot back the
same way before it places replicas on a target it marked, a prepared
one or its own leftover.

The reap runs after the definition is deleted and before the delete
is answered, detached from its caller on a 30s budget, and a mark
left by a process that died expires. A kept or failed reap is logged
and carried in the answer to the delete as a warning; the delete
stands either way. A delete that was issued is read off the snapshot
itself: the store now surfaces DELETE on a snapshot a finalizer still
holds, the way it does for resources, and the snapshot list no longer
stamps SUCCESSFUL beside it.

A later `rd d` of the source names what is still there: a snapshot
safe to delete, one being deleted that needs only a retry shortly,
one kept because a named definition restores from it, and one that
looks like a clone's but was never stamped.

Assisted-by: LLM
Signed-off-by: Andrei Kvapil <kvapss@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant