-
Notifications
You must be signed in to change notification settings - Fork 41.9k
Run RWOP preemption test as serial #135623
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
Please note that we're already in Test Freeze for the Fast forwards are scheduled to happen every 6 hours, whereas the most recent run was: Fri Dec 5 09:34:09 UTC 2025. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jsafrane The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/priority important-soon |
1e4d02d to
cc96b37
Compare
|
/retest-required |
It needs to run as [Serial], so it accidentally does not evict other Pods. Consider this scenario on a busy clusters, with all nodes at their attachment limit. 1. pod1 of the preemption test runs, pod2 is created. 2. The scheduler evicts pod1. That frees the RWOP volume and it also frees the last attachment slot on the node. 3. Some other e2e tests creates a Pod and scheduler puts it on a node, taking the last attachment slot. 4. The scheduler schedules pod2 agaian and it sees there is no node with a free attachment slot -> new round of eviction, now evicting a pod of unrelated e2e tests. The unrelated test will fail.
cc96b37 to
618bec8
Compare
Co-authored-by: Patrick Ohly <patrick.ohly@intel.com>
What type of PR is this?
/kind bug
/kind flake
What this PR does / why we need it:
The test
should preempt lower priority pods using ReadWriteOncePod volumesneeds to run as[Serial], so it accidentally does not evict other Pods.Consider this scenario on a busy clusters, with all nodes at their attachment limit.
Which issue(s) this PR is related to:
Fixes #135622
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: