fix refresh race: wait for kustomize rollouts before restarting pods - #178
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: omer-vishlitzky The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Caution Review failedFailed to post review comments WalkthroughThe script now runs background cert-manager certificate waits and parallel ChangesDeployment Readiness & AAP Restart
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Caution Pre-merge checks failedPlease resolve all errors before merging. Addressing warnings is optional.
❌ Failed checks (1 error, 2 warnings)
✅ Passed checks (8 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 |
Kustomize apply changes deployment images, triggering rollouts that run DB migrations. The restart in step [4/8] killed those pods mid-migration, leaving the database dirty and crash-looping all subsequent pods. Wait for kustomize-triggered rollouts in parallel with TLS cert waits so migrations complete before the restart. No duration impact since both waits overlap. Co-Authored-By: Claude <noreply@anthropic.com>
5c0aa46 to
83b3731
Compare
|
/retest |
After recert the kube-apiserver restarts, breaking the controller-task's in-cluster connections. The pod reports Running but its scheduler can't launch jobs via container groups, causing the first provision jobs to fail with rc=None. Delete and wait for the controller-task pod inside wait_aap_controller (which already runs in parallel), then re-verify the gateway responds. Co-Authored-By: Claude <noreply@anthropic.com>
|
/retest |
|
/lgtm |
Summary
Fixes a race condition in
refresh-after-snapshot.shwhereoc rollout restartin step [4/8] kills pods that were started by the kustomize apply in step [3/8], interrupting in-flightDB migrations and leaving the database in a dirty state.
What happens:
oc apply -kchanges the fulfillment-service image → Kubernetes creates new pods that start running DB migration Noc rollout restart→ kills those pods mid-migrationversion: N, dirty: true→ every subsequent pod crashes with "Dirty database version N"Evidence from this CI
run:
"version":43,"dirty":false— cleanrollout restart"version":44,"dirty":true→Dirty database version 44. Fix and force version.→ CrashLoopBackOffFix: Wait for kustomize-triggered rollouts in parallel with the TLS cert waits, so migrations complete before the restart. Zero duration impact since both wait groups overlap.
Test plan
Summary by CodeRabbit