Repository navigation
fix: import dynamic CSI snapshot handles for PSQLBranches - #37
Conversation
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (4)
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe branch state now prefers ChangesSnapshot handle selection
Priority: ➖ Normal Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix Merge Risk: ⚪ Minimal · up to The branch import change is ready to merge after normal checks; the supplied evidence identifies no unresolved issue requiring a code change. Security Architecture ReviewSecurity architecture risk: 🔵 Low · up to Dynamic snapshot recovery now trusts an identifier reported by the source snapshot controller. The existing import retains the physical snapshot and waits for readiness before reporting recovery complete, but it can create import content before the source content is ready. The authorization and provenance guarantees for the reported identifier remain unverified. Retained concerns
Security review detailsSecurity Blast Radius
Trust Boundaries and Controls
Hardening Proposals
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
Published Crossplane PackageThe following Crossplane package was published as part of this PR: Package: ghcr.io/hops-ops/psql-stack:pr-37-1f7c3736e48d442a2dfc52403d7008fe80d48f55 |
Summary
Fix cross-namespace PSQLBranch recovery from dynamically created CSI snapshots. Read
VolumeSnapshotContent.status.snapshotHandle, withspec.source.snapshotHandleas the fallback for pre-provisioned snapshots.Dynamic content identifies the original volume in
spec.source.volumeHandleand reports the created snapshot ID in status. Previously the branch function found no handle and emitted only the source Cluster observation, source VolumeSnapshot, and source content observation. It never created branch import resources, recovered CNPG clusters, or app credential Secrets.Preserve the existing static-import test and add a dynamic-source regression that expects the snapshot ID rather than the volume ID. Update staged and ready fixtures to match the actual dynamic CSI shape.
Reproduction and verification
Replayed both stuck production previews with their captured XR and observed Object state. Local replay removes server ownership metadata; snapshot spec/status fields are unchanged. No production resources were modified.
snap-0150cca495c196e6bsnap-028d83c31f9c34bdbAssertions verified that the imported content uses the actual
ebs.csi.aws.comdriver, the snapshot ID rather than the source volume ID,deletionPolicy: Retain, and a matching branch snapshot binding. Both replays correctly remain unready and defer CNPG creation until the imported snapshot becomes ready.git diff --checkComposition test job.
Local
up test runstalled after its first render and was terminated; the successful suite result above is from CI. Both production-state replays completed locally.The existing AWS E2E exercises same-namespace branching; the added composition regression and production replays exercise the cross-namespace path involved in this incident. Actual preview recovery and generated Secrets must be verified after the fixed package is released and adopted through GitOps.