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
Revert changes to WaitForStableCluster in scheduler e2e test #84988
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ahg-g 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 |
7763b8f
to
c58da39
Compare
c58da39
to
f4e4fb1
Compare
/cc @damemi |
can we trigger the conformance test here, or we have to wait for this get merged into master |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
Thanks
Did this change break the test further? Or just not address the flake? |
"Partially fixes" in the PR description will still close the issue. Is that intended? |
Broke it further. |
It actually fixes that specific flake, so should be fixes rather than partially. |
What type of PR is this?
/kind flake
What this PR does / why we need it:
#84806 changed the condition for waiting for a "stable cluster" in e2e tests. Originally we waited for all pods in the system to schedule, #84806 changed that to wait until there are no pods in any namespace other than kube-system (and be in scheduled state).
The reason we did that is because we wanted to wait until pods that were created by other tests to actually be deleted, and the assumption was that those pods are created in namespaces other than kube-system.
We don't have good insight to why this didn't work since we don't have enough logs from the test. For now, this PR reverts to the old condition, and in a follow up PR we will try another approach to wait for pods that are subject to deletion to actually get deleted. Perhaps what we should wait for is for pods in deleted namespaces to disappear.
Which issue(s) this PR fixes:
Partially Fixes #84980
Does this PR introduce a user-facing change?: