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
test: demote service ClientIP affinity timeout tests from conformance #112806
test: demote service ClientIP affinity timeout tests from conformance #112806
Conversation
@dcbw: 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/test-infra repository. |
/label area/conformance |
@dcbw: The label(s) In 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/test-infra repository. |
/retest |
kubernetes/test/e2e/network/service.go Lines 3403 to 3408 in cf6a086
|
Sorry, I misread it, this is about the timeout option, I fully agree, a conformance test should not be doing assumption on the backend /lgtm /assign @johnbelamaric @smarterclayton For conformance approval |
@johnbelamaric what do you think? |
During the September 29th, 2022 SIG-Network meeting we decided to demote the two affinity timeout conformance tests. This was because: (a) there is no documented correct behavior for these tests other than "what kube-proxy does" (b) even the kube-proxy behavior differs depending on the backend implementation of iptables, IPVS, or [win]userspace (and winkernel doesn't at all) (c) iptables uses only srcip matching, while userspace and IPVS use srcip+srcport (d) IPVS and iptables have different minimum timeouts and we had to hack up the test itself to make IPVS pass (e) popular 3rd party network plugins also vary in their implementation Our plan is to deprecate the current affinity options and re-add specific options for various behaviors so it's clear exactly what plugins support and which behavior (if any) we want to require for conformance in the future. Signed-off-by: Dan Williams <dcbw@redhat.com>
fd20d89
to
1687916
Compare
/lgtm |
In general, demoting tests isn't too controversial, at least it won't cause problems for any existing distros. Theoretically it could cause problems for users, but given your statements regarding the level of inconsistency in existing implementations, I think that's not an issue. /approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dcbw, johnbelamaric 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 |
/retest |
…6-upstream-release-1.24 Automated cherry pick of #112806: test: demote service ClientIP affinity timeout tests from
…-upstream-release-1.25 Automated cherry pick of #112806: test: demote service ClientIP affinity timeout tests from
During the September 29th, 2022 SIG-Network meeting we decided to demote the two affinity timeout conformance tests. This was because:
Our plan is to deprecate the current affinity options and re-add specific options for various behaviors so it's clear exactly what plugins support and which behavior (if any) we want to require for conformance in the future.
/kind cleanup
@thockin @danwinship @aojea @kubernetes/sig-network-misc