Repository navigation
Add a data-preserving audit-volume capacity recovery operation #4820
Description
🤖 Generated by the Agentic Engineer
Description
The configured audit claim request is not proof of actual capacity or free space. OpenBao's file audit backend appends indefinitely and can block service when its available audit devices cannot write. Deliver a bounded headroom operation without altering the immutable StatefulSet claim templates or deleting audit evidence.
Steps to Reproduce
- Compare requested and observed capacity of the three fixed audit claims using private read-only evidence.
- Check the audit-volume usage separately from the data volumes.
- The public configuration has no reviewed capacity recovery operation; its old growth estimate cannot establish current headroom.
Expected Behavior
A separately confirmed main workflow may increase only the three fixed audit claims to 20 GiB, preserving claim/PV/storage identities, other specification fields, audit configuration and database service. It does not solve archival or authorize any deletion.
Acceptance Criteria
- Confirm source/main, the accepted deployed revision and a healthy three-replica OpenBao workload before writes.
- Verify complete, reciprocal Bound PVC/PV identities and the existing expansion-capable storage class; absent, terminating, replaced or ambiguous resources stop the operation.
- Use UID/resourceVersion-preconditioned writes with a fixed 20 GiB maximum. Never shrink, replace a claim, change a StatefulSet template, delete a record, change the data claims or disable an audit device.
- Acknowledge the recurring capacity cost before production execution, capped at the approved amount; expansion cannot be rolled back by shrinking.
- Show test-first missing-evidence, wrong-volume, conflict and ambiguous-write controls, plus a complete successful expansion/readback path. A failed attempt is not automatically replayed.
- Prove each original UID/storage handle persists, capacity reaches the intended size and OpenBao remains available in separated readbacks. Keep raw audit content and production telemetry private.
- Replace the speculative growth estimate with a measurement and headroom procedure.
Additional Context
This is an additive headroom slice of #4671, not completion of its durable archival, retention or rotation obligations. No production mutation or audit-content access has been performed. Do not add destructive rotation or cleanup until archival acceptance is defined and proven.
Part of #4671.
Activity
chore: agent-claim #4820 nonce=8cf446fc5e3dd73fecfd1c8708f596b1
devantler commentedon Oct 13, 2026
The operation is merged as #4822 / 5e833c6, and its accepted production deployment38360163854 succeeded. Protected expansion38363326775 then stopped with HOLD before creating the consumption receipt. Independent OIDC reads confirm all three audit requests/capacities are unchanged, all seven original claim/binding identities remain intact, and the receipt is absent. No storage patch or local production exec was performed.
Fresh source/deployment records and OIDC source-generation, binding and mount checks remain valid. Coroot still shows the two audit volumes above the existing80% threshold, not a full filesystem. The current failure output does not distinguish price, accepted-deployment, metadata and service-health checks. Add a regression-tested read-only preflight and bounded stage diagnostics before another attempt; do not guess the cause, relax the cap/health checks, or replay a write.
Keep #4820 open/Verifying until the approved protected execution and separated live proof complete. Long-term archival/retention remains #4671.
chore: agent-claim #4820 nonce=177f919d72480042f8abd0513d202ee8
chore: agent-claim #4820 nonce=b1b4f6b84b1c2f88095c51ec5551d039
devantler commentedon Oct 13, 2026
The approved capacity recovery is complete, including live verification.
All acceptance criteria for this bounded capacity slice are met. Closing it does not close #4671: durable archival, readability/restore proof and retention remain separate work. This is not a claim that every platform alert or historical log error has cleared.