-
Notifications
You must be signed in to change notification settings - Fork 40.1k
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
e2e daemonset: stronger health check of DaemonSet status #127988
e2e daemonset: stronger health check of DaemonSet status #127988
Conversation
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
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
LGTM label has been added. Git tree hash: 48f89956d4ea9d711aaf6f6133b59f93b71e6cac
|
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.
for some reason
ERROR: test/e2e/framework/daemonset/fixtures.go:150:5: badCond: `desired == scheduled && desired == ready` condition is suspicious (gocritic)
ERROR: if desired == scheduled && desired == ready {
ERROR: ^
The Kubernetes project has merge-blocking tests that are currently too flaky to consistently pass. This bot retests PRs for certain kubernetes repos according to the following rules:
You can:
/retest |
1 similar comment
The Kubernetes project has merge-blocking tests that are currently too flaky to consistently pass. This bot retests PRs for certain kubernetes repos according to the following rules:
You can:
/retest |
/hold |
The error was only generated if both checks (generated pods and ready pods) failed. This looks like a logic error, failing if either of those isn't matching expectations seems better.
0387e7e
to
3ec8437
Compare
That linter check is a false positive. Luckily, we can trick it without having to go back to the previous double-negotiation approach: diff --git a/test/e2e/framework/daemonset/fixtures.go b/test/e2e/framework/daemonset/fixtures.go
index 6ae6fd10341..ed725010224 100644
--- a/test/e2e/framework/daemonset/fixtures.go
+++ b/test/e2e/framework/daemonset/fixtures.go
@@ -147,7 +147,7 @@ func CheckDaemonStatus(ctx context.Context, f *framework.Framework, dsName strin
return err
}
desired, scheduled, ready := ds.Status.DesiredNumberScheduled, ds.Status.CurrentNumberScheduled, ds.Status.NumberReady
- if desired == scheduled && desired == ready {
+ if desired == scheduled && scheduled == ready {
return nil
}
return fmt.Errorf("error in daemon status. DesiredScheduled: %d, CurrentScheduled: %d, Ready: %d", desired, scheduled, ready) |
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
LGTM label has been added. Git tree hash: bbad676c43163b2e7395bf01e410f265f198cb8e
|
/hold cancel
lol /approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: aojea, pohly 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 |
should we expect some flakes after this of tests doing wrong assumptions 🤔 |
I don't think so. The tests that call this seem to use it as additional sanity check after waiting for the pod(s) to run, in which case all three values should be equal. |
it seems it happen :) #128049 |
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
The error was only generated if both checks (generated pods and ready pods) failed. This looks like a logic error, failing if either of those isn't matching expectations seems better.
Does this PR introduce a user-facing change?