k8s snapshots: mark and reclaim retained PVCs left by a restore

Open
#3,304 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
go, kubernetes

Research direction

Start with the review discussion on PR #3179 and the existing snapshot restore flow; this issue says the API needs a design pass and is blocked until that PR lands. Then read docs/K8S-SNAPSHOT-BACKUPS.md and decide the typed listing and removal API, following the issue’s proto-first and generated-client guidance. Done means retained PVCs can be identified and listed per tenant, removal refuses claims mounted by running pods with a test, and the docs explain retention and reclamation.

Written by the indexing model from the issue text.

Description

enhancement needs-decision runtime:claude size:M

Follow-up from the early review of draft PR #3179 (K8s CSI snapshot backups, #3168): https://github.com/FootprintAI/Containarium/pull/3179#pullrequestreview-5711286956. Not blocking that PR; decide and schedule after it lands.

Problem

A snapshot restore creates a new PVC in the source namespace and leaves the previous data claim, and the claim from a failed restore, in place so nothing is lost. Those retained PVCs carry no marker, no cleanup path and no documentation, so storage cost grows without bound with every restore.

Proposal (to be confirmed in the design pass)

  • Label or annotate each retained PVC with what it is (previous data claim or failed-restore claim), the box, the snapshot it relates to and when it was retained.
  • Add a typed way to list and remove them, CLI-first (a containarium subcommand over the generated client, proto-first for any new RPC; no hand-rolled HTTP handler), with an age-out option and a dry-run.
  • Document the retention behaviour in docs/K8S-SNAPSHOT-BACKUPS.md.

Open questions (defaults)

  • Default age-out for retained PVCs: none, delete only on explicit command (default), or a configurable TTL?
  • Should a retained previous claim be removed automatically after a restore has been verified Ready for some interval (default: no)?

Acceptance criteria

  • Retained PVCs are identifiable (label or annotation) and listable per tenant, with authorization the same as snapshot Create/Restore/Delete (AuthorizeTenant).
  • A removal command refuses to delete a claim still mounted by a running pod, with a test that fails if the check is removed.
  • The docs describe what is retained, why and how to reclaim it.

Scope

Design pass needed for the API. Blocked by #3179. Refs #3168, #3179.

🤖 Generated with Claude Code

Dominant language
Go
Stars
296
Forks
38
Avg merge
7h 34m
Merged PRs (30d)
631

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from FootprintAI/Containarium

All issues in FootprintAI/Containarium

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.