Skip to content
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

Clean up SCTP tests #96717

Open
danwinship opened this issue Nov 19, 2020 · 5 comments
Open

Clean up SCTP tests #96717

danwinship opened this issue Nov 19, 2020 · 5 comments

Comments

@danwinship
Copy link
Contributor

@danwinship danwinship commented Nov 19, 2020

When we first added SCTP tests, we thought that we weren't going to be able to do actual tests of SCTP network connectivity within kubernetes CI, so we came up with a plan involving a split between tests that involve actual SCTP network connectivity (which require the SCTP kernel module to be available) and tests that don't do SCTP network traffic and so can run anywhere. That way we could still test some basic functionality even if we couldn't test that SCTP actually worked. Then we got a little bit crazy with the non-connectivity-checking tests, poking around at iptables to try and confirm they were doing the right thing even though we couldn't send SCTP packets to test them the right way.

In fact, it turns out we can run the connectivity tests in kube CI under kind, so the split wasn't really necessary and should be cleaned up now.

I. Flip the use of [Disruptive]

The non-connectivity-checking ([Feature:SCTP]) tests conflict with the connectivity-checking ([Feature:SCTPConnectivity]) ones, because the former tests use CheckSCTPModuleLoadedOnNodes to verify that running the test itself doesn't cause the sctp.ko kernel module to be loaded on any nodes, while the latter tests may cause the module to be loaded as a side effect of being the first process on a node to open an SCTP socket.

In the current code, we handle this by marking the [Feature:SCTPConnectivity] tests as [Disruptive] but now I think this is backward; while it's true that it's the connectivity tests that have a side effect, it's only a "disruptive" side effect because the kernel-module-checking tests are inherently non-parallel-testing-friendly. So we should remove the [Disruptive] from the [Feature:SCTPConnectivity] tests, and add it to the non-connectivity tests, as described below.

II. Simplify the core [Feature:SCTP] tests

The three [Feature:SCTP] tests in test/e2e/network/service.go ("should allow creating a basic SCTP service with pod and endpoints", "should create a ClusterIP Service with SCTP ports", and "should create a Pod with SCTP HostPort") are doing three things:

  1. making sure the API works
  2. poking around at iptables to see if kube made the rules we think it should have made
  3. confirming that running the test doesn't cause the kernel to load the sctp.ko kernel module

1 is completely redundant with the "connectivity" tests. 2 is unnecessary given the connectivity tests, and very fragile anyway. 3 is still important (for both functionality and security reasons; see the KEP for details).

The three tests should be replaced with a single simpler test, something like "should allow creating Pods, Services, and NetworkPolicies with SCTP ports". (It probably doesn't belong in service.go any more at this point though.) It doesn't try to use the Pod/Service/NetworkPolicy it creates, it just confirms that (a) you can create them, and (b) the result of CheckSCTPModuleLoadedOnNodes doesn't change from the start of the test to the end of the test

And while we're fixing things, the new combined test doesn't need to be labelled [Feature:SCTP] any more, since SCTP is no longer gated.

III. Simplify "should not allow access by TCP when a policy specifies only SCTP" just a little

The one test in test/e2e/network/network_policy.go that is [Feature:SCTP] rather than [Feature:SCTPConnectivity] is "should not allow access by TCP when a policy specifies only SCTP". This makes sure network plugins that don't implement SCTP don't misinterpret policies containing protocol: SCTP, so we don't want to move it into the [Feature:SCTPConnectivity] suite (since we specifically want this test to be run by some people who are intentionally skipping the [Feature:SCTPConnectivity] tag).

So it should stay mostly as is, except that, like above, it doesn't need to be labelled [Feature:SCTP] any more. And we can remove the CheckSCTPModuleLoadedOnNodes check here, because that's now redundant with the new "should allow creating Pods, Services, and NetworkPolicies with SCTP ports" test.

IV. Drop the SCTP-only periodic job(s?)

There are one or more periodic jobs testing the [Feature:SCTP] tests left over from when SCTP was alpha and not enabled by default (eg https://testgrid.k8s.io/sig-network-gce#ubuntu-gce-basic-sctp), but they can go away now.

@danwinship
Copy link
Contributor Author

@danwinship danwinship commented Nov 19, 2020

/sig network
/triage accepted
/kind cleanup
/remove-kind bug
/help
/good-first-issue
/cc @aojea

@k8s-ci-robot
Copy link
Contributor

@k8s-ci-robot k8s-ci-robot commented Nov 19, 2020

@danwinship:
This request has been marked as suitable for new contributors.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.

In response to this:

/sig network
/triage accepted
/kind cleanup
/remove-kind bug
/help
/good-first-issue
/cc @aojea

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.

@theunrealgeek
Copy link

@theunrealgeek theunrealgeek commented Nov 20, 2020

@danwinship I'm new to contributing to kubernetes, so I might be slow and take some time to get this done, but would love to take it up. Seems pretty interesting

@FreeZhang61
Copy link
Contributor

@FreeZhang61 FreeZhang61 commented Nov 20, 2020

/assign

@cmluciano
Copy link
Member

@cmluciano cmluciano commented Dec 1, 2020

@FreeZhang61 @theunrealgeek Have either of you had some time to take a look at this issue? There are a few pieces that can probably be worked in parallel.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.