feat: cleanup candidate reservations when confirming vm#871
feat: cleanup candidate reservations when confirming vm#871juliusclausnitzer wants to merge 6 commits into
Conversation
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe PR adds a field index to track reservation allocations by VM UUID and implements controller logic that removes newly confirmed VMs from candidate reservations. Tests validate cleanup behavior across multiple candidates and reconciliation flows. ChangesReservation Allocation Cleanup by VM UUID
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@internal/scheduling/reservations/commitments/reservation_controller.go`:
- Around line 398-403: The current logic copies
res.Status.CommittedResourceReservation.Allocations into
existingStatusAllocations and later uses presence in status to skip cleanup,
which allows a transient cleanup failure to be permanently skipped on the next
reconcile; change the reconcile/cleanup flow in reservation_controller.go so
cleanup of stale candidate allocations is not gated solely by membership in
res.Status.CommittedResourceReservation.Allocations: compare
existingStatusAllocations to the new patched allocations and only mark candidate
allocations removed when the cleanup step actually succeeded, and if the
patch/cleanup fails do not mutate status to record the VM as cleaned;
specifically update the code that reads/writes
res.Status.CommittedResourceReservation.Allocations and the cleanup branch (the
blocks around existingStatusAllocations and the cleanup calls referenced in your
comment) to always retry cleanup for VMs whose candidate allocations remain
stale until cleanup returns success (or add an explicit per-VM cleanup-needed
flag/finalizer in status that you clear only after successful cleanup).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 8d9d8ac7-752f-4ae0-bbfc-99d65b9ce8b2
📒 Files selected for processing (5)
internal/scheduling/reservations/commitments/committed_resource_controller_test.gointernal/scheduling/reservations/commitments/field_index.gointernal/scheduling/reservations/commitments/integration_test.gointernal/scheduling/reservations/commitments/reservation_controller.gointernal/scheduling/reservations/commitments/reservation_controller_test.go
Test Coverage ReportTest Coverage 📊: 69.6% |
No description provided.