Orphan sweep: report and document PVCs kept on missing records
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 77/100
- Issue type
- Feature
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- kubernetes, typescript
- Domain
- backend, documentation
Research direction
Find the orphanSweeper implementation and its SweepResult definition, then read docs/context-service.md and the existing sweep tests. Add the kept PVC count and summary described in the issue, and document how kept claims affect quota and how operators can find and remove them. Done when the summary is covered by tests and the documentation includes those steps.
Written by the indexing model from the issue text.
Description
Follow-up to Paolo's suggestion on #615 (sweep orphaned workload sandboxes).
When a workload's record is missing, the orphan sweep deletes its StatefulSet, Secret and Service but keeps its PVC, so a wrong or emptied Redis can never delete user data. Nothing collects those kept PVCs afterwards: they stay until an operator runs kubectl -n moca-sandbox delete pvc <wl>, and they count against the moca-sandbox ResourceQuota (persistentvolumeclaims: 32, requests.storage: 320Gi). If the per-pass kept PVC log line is missed, new mounted workloads eventually fail to create a PVC on quota.
Proposed
- Add a
keptcount toSweepResult, and a "N PVC(s) kept on missing records" summary line inorphanSweepernext toswept. - In
docs/context-service.md, note that kept claims count against the quota, and how to find and remove them.
- Dominant language
- TypeScript
- Stars
- 5
- Forks
- 11
- Avg merge
- 8h 58m
- Merged PRs (30d)
- 154
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from rossoctl/moca
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
rossoctl/moca#421 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
keptinventory/kept#336 ·
Maintainers usually reply within 1 day
-
good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
hemi-earn
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
vetro-protocol/vetro-monorepo#1013 ·
Maintainers usually reply within 1 day