e2e/loadbalancer: fix e2e by skipping unscheduled nodes on discovery#1340
Conversation
|
This issue is currently awaiting triage. If cloud-provider-aws contributors determine this is a relevant issue, they will accept it by applying the The DetailsInstructions 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. |
|
/test pull-cloud-provider-aws-e2e-kubetest2-quick |
508f0af to
af4ed8d
Compare
|
/test pull-cloud-provider-aws-e2e-kubetest2-quick |
|
Tests The other issues are unrelated to this change. |
|
/lgtm |
|
@jcpowermac: changing LGTM is restricted to collaborators DetailsIn response to this:
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. |
|
Thanks @mtulio /assign @kmala @yue9944882 @elmiko |
|
/test pull-cloud-provider-aws-e2e-kubetest2-quick |
1 similar comment
|
/test pull-cloud-provider-aws-e2e-kubetest2-quick |
|
@kmala sounds like the pull-cloud-provider-aws-e2e-kubetest2-quick job has been permafailing for a while now. So very probably unrelated to this PR.
Given the full test pull-cloud-provider-aws-e2e-kubetest2 passed, are we ok ignoring the quick one and merge the PR? TY |
elmiko
left a comment
There was a problem hiding this comment.
makes sense to me, just have a question.
af4ed8d to
c560eee
Compare
c560eee to
5873ed8
Compare
Skip unsupported or unscheduled worker nodes when discovering candidates for load balancer scenarios. Some tests, such as hairpin traffic, discover worker nodes using the node-role.kubernetes.io label. If a discovered node has NoSchedule or NoExecute taints, the test fails because the workload is implemented generically and does not define specific tolerations. Filtering these nodes during discovery ensures the test selects a candidate capable of hosting the workload without requiring changes to the test's pod specification.
5873ed8 to
add3c4d
Compare
|
/test pull-cloud-provider-aws-e2e-kubetest2-quick |
|
yeah, following Dam's comment above, pull-cloud-provider-aws-e2e-kubetest2 is permafailing, looks like caused by CI infra connectivity issues. @elmiko , feedback addressed! |
|
/test pull-cloud-provider-aws-e2e-kubetest2-quick |
Hey @kmala , the test has been fixed with PR kubernetes/test-infra#36535, would you mind taking a look, please? Thanks! |
The otel SDK bump to v1.40.0 fixes the CVE GO-2026-4394 that was causing the govulncheck to fail. Otel packages bumped from v1.36.0 → v1.40.0: - go.opentelemetry.io/otel - go.opentelemetry.io/otel/metric - go.opentelemetry.io/otel/sdk (this fixes GO-2026-4394) - go.opentelemetry.io/otel/trace - go.opentelemetry.io/auto/sdk (v1.1.0 → v1.2.1) Transitive dependency also updated: - golang.org/x/sys (v0.38.0 → v0.40.0)
|
Hey @kmala , thanks! just bumped to fix otel dependency in commit go.mod: otel SDK bump to v1.40.0 fixes the CVE GO-2026-4394, govulncheck is now passing. Would you mind taking a look again, please? |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kmala, nrb The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |

What type of PR is this?
/kind bug
/kind failing-test
/kind flake
What this PR does / why we need it:
Skip unsupported or unscheduled worker nodes when discovering candidates for load balancer scenarios.
Some tests, such as hairpin traffic, discover worker nodes using the node-role.kubernetes.io label. If a discovered node has NoSchedule or NoExecute taints, the test fails because the workload is implemented generically and does not define specific tolerations.
Filtering these nodes during discovery ensures the test selects a candidate capable of hosting the workload without requiring changes to the test's pod specification.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?: