Repository navigation
fix(apps/kubernetes): bump tenant Cilium HR install timeout 10m -> 15m - #3230
IvanHunters wants to merge 1 commit into
Conversation
The tenant Cilium HR's `spec.timeout: 10m` races the image pull to a fresh Talos worker VM on CI runners. Analysis of cozyreport artifact from the E2E run 28843794670 (job 85543970802) on the `kubernetes- previous` test: - Every Cilium init container on the tenant node is stuck with `state: waiting, reason: PodInitializing` and `imageID: ""` — kubelet is still fetching `iad.ocir.io/.../cozystack/cilium:main@sha256:...` when the 10m HR install timeout fires. - `cilium-agent`'s `current.log` and `previous.log` are both zero bytes — the container never entered the running phase. - On the same run, `kubernetes-latest` (v1.35.6) took 13:10 wall-clock and passed; `kubernetes-previous` (v1.34.9) took 13:52 and failed. Both minors sit right on the edge of the 10m HR budget; whichever test races the pull first wins. The delta is not version-specific. 15m matches the tenant Kubernetes install budget already used by the outer HR and by the monitoring chart's cozyrds annotation. Cilium's install work itself completes in seconds — the extra headroom is purely to absorb slow first-time image pulls on runners without a warm mirror cache. Closes #3229. Signed-off-by: IvanHunters <[email protected]>
|
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 (1)
📝 WalkthroughWalkthroughThe Cilium HelmRelease reconciliation timeout in cilium.yaml is increased from 10m to 15m, accompanied by expanded explanatory comment text. No other logic or values are changed. ChangesCilium HelmRelease timeout update
Estimated code review effort: 1 (Trivial) | ~2 minutes Possibly related PRs
Suggested reviewers: 🚥 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 |
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 increases the HelmRelease installation timeout for Cilium to provide sufficient headroom for image pulling on cold-booted Talos worker nodes in CI environments. By aligning this timeout with the existing tenant Kubernetes install budget, the change prevents premature installation failures and ensures more reliable test execution. 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 the timeout for the Cilium HelmRelease from 10m to 15m to prevent timeouts during image pulls on slow CI runners. The reviewer noted that the PR title and release-note block should use the scope kubernetes instead of apps/kubernetes to adhere to the repository's style guide.
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.
| # Cilium container image lives in the OCIR mirror and the tenant node | ||
| # has no image cache on first boot; the 10m timeout raced the pull | ||
| # about half the time (~13m wall-clock, see cozystack/cozystack#3229). | ||
| timeout: 15m |
There was a problem hiding this comment.
The PR title and release-note block use the scope apps/kubernetes. According to the repository style guide, the valid scope for this package is kubernetes (under the Apps category). Please update the PR title and release-note block to use kubernetes as the scope (e.g., fix(kubernetes): ...).
References
- Each commit must follow Conventional Commits format with a valid scope. For the kubernetes package, the valid scope is 'kubernetes', not 'apps/kubernetes'. (link)
myasnikovdaniil
left a comment
There was a problem hiding this comment.
It is completely wrong direction of fix
|
I'll bring you issue soon |
|
Closing per myasnikovdaniil's review + #3231 analysis. Verified against the cozyreport artifact from the failing run: the Both attempts on this PR (10m → 15m No follow-up commits on this branch; safe to delete |
Summary
The tenant Cilium HR's install timeout races the container image pull to a fresh Talos worker VM on CI runners. Bump
spec.timeoutonpackages/apps/kubernetes/templates/helmreleases/cilium.yamlfrom 10m to 15m — aligned with the tenant Kubernetes install budget the rest of the stack already uses.Root cause (from CI artifact analysis)
Reproduced on E2E run 28843794670 (job 85543970802) — the same failure signature seen on 6+ open PRs at time of writing, tracked in #3229.
Cozyreport artifact from that run, looking at
snapshots/kubernetes-previous/tenantkubeconfig-test-previous-version/namespaces/cozy-cilium/v1/pod/cilium-*.yaml:cilium-agentcurrent.logandprevious.logare zero bytes — the container never entered running phase because every init container was still waiting foriad.ocir.io/idyksih5sir9/cozystack/cilium:main@sha256:16e9a5cd3b3614571329a309fc283f5a43e7522bef91d1ff539545c0ec1bc857to land. The HR's 10m installtimeoutfires, helm-controller uninstalls, retries viaretries: -1, next install races the pull again.The failure is not version-scoped:
until nodes Readybats budget)Both tests sit right on the edge; whichever races the pull first wins. Cilium's own startup work (once running) completes in seconds, so 15m is pure headroom for slow first-time image pull on a runner without a warm mirror cache. Matches the 15m budget the outer tenant HR and the monitoring cozyrds annotation already use elsewhere.
Alternative fixes considered
Test plan
kubernetes-latestandkubernetes-previousE2E tests both pass on the next CI run against this branch.helm install --waitdeadline; interval and reconcile cadence unchanged).Closes #3229.
Release note
Summary by CodeRabbit