fix(e2e): size tenant workers by resources, not by u1.large - #3840
Merged
Aleksei Sviridkin (lexfrei) merged 1 commit intoAug 15, 2026
Merged
Conversation
Sizing the workers with u1.large doubled their memory along with the vCPUs, and four 8Gi workers do not fit on the sandbox beside the rest of the suite: the second worker of each cluster stayed Pending with Insufficient memory on all three nodes, so the node group could never reach two Ready nodes and node-join failed for a reason that has nothing to do with the CPU ceiling it was meant to test. Setting resources.cpu and resources.memory keeps the two vCPUs at the memory the workers had before. The chart drops the instancetype from the VM when a group sets both, and the values schema still requires the field, so it stays in the values as the sizing fallback it now is. Assisted-By: Claude <noreply@anthropic.com> Signed-off-by: Aleksei Sviridkin <3811295@gmail.com>
Aleksei Sviridkin (lexfrei)
requested review from
Andrei Kvapil (kvaps),
Timofei Larkin (lllamnyp) and
myasnikovdaniil
as code owners
August 15, 2026 15:34
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe tenant worker node group now uses ChangesTenant worker configuration
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This localized e2e sizing change preserves two vCPUs while reducing worker memory to 4Gi, with no actionable merge-blocking risk remaining after normal checks and review. Possibly related PRs
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 |
Aleksei Sviridkin (lexfrei)
deleted the
fix/e2e-worker-vcpu-without-memory-bump
branch
August 15, 2026 15:37
This was referenced Aug 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this PR does
Follow-up to #3839, which moved the e2e tenant workers to
u1.largeto give them a second vCPU. That instancetype doubles memory along with the vCPUs, and four 8Gi workers do not fit on the sandbox beside the rest of the suite. On the first runs after it landed, the second worker of each cluster stayed Pending with0/3 nodes are available: 3 Insufficient memory, so the node group never reached two Ready nodes and node-join failed for a reason unrelated to the CPU ceiling the change was meant to test. The memory estimate in that PR body counted the workers against total node memory and did not account for what the rest of the suite already occupies.This sizes the group with
resources.cpuandresources.memoryinstead, which keeps the two vCPUs at the 4Gi the workers had before. The chart omits the instancetype from the VM whenever a group sets both fields, since KubeVirt rejects a VM that references an instancetype and also overrides CPU or memory, and the values schema still listsinstanceTypeas required, so it stays in the values as the fallback it now is.The measurement from those runs is worth keeping even though the runs were spoiled. Where the workers did start, the two-scrape capture read 1.46 to 1.93 against the new ceiling of 2.0, with 2 to 5 percent of CFS periods throttled, against 0.93 to 0.98 of a 1.0 ceiling at 8 to 13 percent throttled before. The ceiling was binding, and raising it does loosen it; whether that is enough to make the join deadline is what the next runs measure.
Screenshots
Not applicable, no UI change.
Downstream repositories
The diff is one values block inside
hack/e2e-chainsaw/_lib/run-kubernetes.sh. Nothing underhack/is moved or renamed, no make target changes behaviour, no package, schema, default or CRD changes. Nothing in the trigger map is touched.Release note
Summary by CodeRabbit
u1.mediuminstances.