fix(e2e): stop the install pipeline flaking (VPA OOM/churn + wait budgets) - #2957
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughThis PR extends e2e test wait timeouts for tenant, service, and Keycloak readiness checks in hack/e2e-install-cozystack.bats, and changes VerticalPodAutoscaler updateMode from Recreate to Initial in vpa-for-vpa.yaml, updating corresponding tests and increasing updater container memory limits/requests in values.yaml. ChangesE2E Readiness Timeout Increases
VPA Update Mode and Resource Sizing
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 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 |
3e2919a to
17568d6
Compare
…tabilization External-mode LinstorCluster driving linstor-csi at the blockstor apiserver; blockstor controller/apiserver/satellite in cozy-linstor. Pins the satellite zvol-device-wait and apiserver RD-404 fix images for e2e validation, and carries the VPA updater OOM/churn fix (#2957) so heavy JVM apps stop OOMKilling on the constrained e2e stand. Signed-off-by: Andrei Kvapil <andrei.kvapil@aenix.io>
The e2e install still flakes on a busy runner where components reach readiness but overshoot tight wait budgets: - keycloak HR chain (keycloak-db CNPG -> keycloak StatefulSet -> keycloak-configure) reaches Ready ~15-18m in: 10m -> 20m. - tenant aggregate wait (hr/etcd hr/ingress hr/monitoring hr/seaweedfs hr/tenant-root): the tenant stack only starts creating pods ~9-10m in and then needs several more minutes: 10m -> 20m. - per-app tenant readiness waits (ingress, etcd, VictoriaLogs/Metrics clusters, grafana-db, grafana): 5m -> 10m. Diagnosed via a live SSH breakpoint: the HRs all do reach Ready, just outside the old budgets. Co-Authored-By: Claude <noreply@anthropic.com> Signed-off-by: Andrei Kvapil <andrei.kvapil@aenix.io>
…tion churn Two root causes of e2e install flakiness, both in the VPA package: 1. The updater memory limit was 110Mi. The updater watches every pod in the cluster, so on a full cozystack install it OOM-kills, which trips the Deployment's ProgressDeadlineExceeded and makes Flux fail the HelmRelease 'early due to stalled resources' - cascading NotReady to monitoring, velero, etcd-operator and everything downstream. Raise the limit to 512Mi (request 200Mi); the recommender is already unlimited. 2. The two VPA-for-VPA VerticalPodAutoscaler objects ran updateMode: Auto, which evicts the VPA recommender(s) during install and adds pod churn on an already busy cluster. Switch to Initial, matching the existing monitoring/etcd VPA->Initial fixes. Co-Authored-By: Claude <noreply@anthropic.com> Signed-off-by: Andrei Kvapil <andrei.kvapil@aenix.io> Signed-off-by: Aleksei Sviridkin <f@lex.la>
17568d6 to
d6f66d2
Compare
|
Rebased onto current Two merge-driven notes: |
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses flakiness in the E2E installation pipeline caused by resource pressure and tight timing constraints. By optimizing resource limits for the VPA updater, adjusting VPA eviction policies to reduce churn, and increasing wait budgets for critical components, the changes ensure more stable and reliable deployments on busy runners. Highlights
New Features🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on Gemini (@gemini-code-assist) comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request increases timeouts in the E2E installation script to prevent premature expiration on loaded runners. It also changes the update mode of the vertical-pod-autoscaler (VPA) components from 'Recreate' to 'Initial' to reduce pod churn during installation, and increases the memory limits and requests for the VPA updater to prevent OOM-kills on full installations. I have no feedback to provide as there are no review comments.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
Aleksei Sviridkin (lexfrei)
left a comment
There was a problem hiding this comment.
Rebased onto current main to revive this install-pipeline flaking fix (VPA updater OOM headroom + wait-budget tuning). Cross-checked with Codex and two independent review passes — no blockers; e2e green and all checks pass. LGTM.
What
The e2e install pipeline still flakes on a loaded runner, failing at a different point each run. Root-caused via repeated runs and a live SSH breakpoint; the platform itself is fine (the components do converge), the failures are slowness + self-inflicted churn under resource pressure.
Fixes
VPA updater OOM — the
vertical-pod-autoscaler-updatermemory limit was110Mi. The updater watches every pod in the cluster, so on a full install it OOM-kills →ProgressDeadlineExceeded→ Flux fails the HelmRelease "early due to stalled resources", cascading NotReady to monitoring, velero, etcd-operator and everything downstream. Raised to512Mi(request200Mi).VPA-for-VPA eviction churn — the two VPA-for-VPA
VerticalPodAutoscalerobjects ranupdateMode: Auto, evicting the VPA recommender(s) during install and adding pod churn on an already busy cluster. Switched toInitial, matching the existing monitoring/etcdVPA->Initialfixes.Install wait budgets — components reach readiness but overshoot tight waits on a busy runner: keycloak HR chain
10m→20m, tenant aggregate wait10m→20m, per-app tenant readiness waits5m→10m.(The crust-gather failure-snapshot timeout that kept whole jobs hanging to the 3h cancel is already on
main.)Release note
Summary by CodeRabbit
Bug Fixes
Tests