test/extended: Add MultiNetworkPolicy IPv4/IPv6 test cases#27795
Conversation
zeeke
changed the title
69002dc to
3a5d626
Compare
|
/retest |
777c99c to
ce758c8
Compare
| o.Eventually(func() error { | ||
| return oc.AsAdmin().Run("get").Args("multi-networkpolicies.k8s.cni.cncf.io").Execute() | ||
| }, "30s", "2s").Should(o.Succeed()) |
There was a problem hiding this comment.
How about to check daemonset, multus-networkpolicy, instead of CRD, to capture multi-networkpolicy-iptables Pod failure before actual tests?
There was a problem hiding this comment.
Good point, it has also been raised here.
From the user perspective, the presence of the CRD is the only sign of the feature, and the daemonset is an implementation detail. In the future, for instance, we can decide to keep the daemonset always up and running but not do anything if the feature is disabled.
But if you think this check can reduce flakiness in some circumstances, I'll go for ti.
There was a problem hiding this comment.
I believe we need to check the daemonset readiness here for further troubleshooting.
Let's imagine we have a trouble in multi-networkpolicy-iptables Pod (like crashed and never goes to 'Running' state). In such case, current test just files error at 'traffic testing': 'podShoudNotReach() is failed'. Usually if we get 'podShouldNotReach() is failed' then we suspect that policy rule/iptables functionality. So it may be hard to proceed to troubleshoot.
If we identify the pod crash here, then easy to understand what is happen, so could you please check DaemonSet readiness, such like that?
origin/test/extended/dr/common.go
Lines 204 to 208 in 9f98fce
There was a problem hiding this comment.
Got it! Thanks for pointing out
| o.Eventually(func() error { | ||
| return oc.AsAdmin().Run("get").Args("multi-networkpolicies.k8s.cni.cncf.io").Execute() | ||
| }, "30s", "1s").Should(o.HaveOccurred()) |
|
/retest |
2 similar comments
|
/retest |
|
/retest |
|
|
||
| g.AfterEach(func() { | ||
| if !previousUseMultiNetworkPolicy { | ||
| disableMultiNetworkPolicy(oc) |
There was a problem hiding this comment.
is this the only test in the entire test suite that does this? because this seems likely to be racy unless you only run tests that do this serially. I think we normally run these kinds of tests at least as serial, if not as disruptive.
testA: sees mutlinetwork is not enabled
testB: sees multinetwork is not enabled
testA: enables multinetwork
testB: enables multinetwork (no-op)
testB: completes
testB: disables multinetwork (because it was not enabled when testB started)
testA: gets broken by multinetwork being disabled in the middle of the test
You could slightly improve the behavior by only disabling multinetwork if this test was the one that enabled it, but you'd still be subject to races in which other tests start, see multinetwork is already enabled(by another test), but than have it disabled out from under them.
There was a problem hiding this comment.
Oh, I haven't thought about it. I think marking them as serial should be enough. They are the only tests that use multinetwork policies.
ce758c8 to
87ba78f
Compare
|
/retest |
87ba78f to
7a7598e
Compare
Test case use Cluster Network Operator field `useMultiNetworkPolicy` field and a basic `deny-all-ingress` policy to ensure the feature is correctly setup. Fixture involves a macvlan net-attach-def and network policy. Connectivity tests are implemented using agnhost http server and cURL. Tested against IPv4 and IPv6 network stacks. Signed-off-by: Andrea Panattoni <apanatto@redhat.com>
7a7598e to
0d6eaf6
Compare
|
/retest |
2 similar comments
|
/retest |
|
/retest |
|
/retest-required |
|
/retest |
|
/lgtm |
|
@bparees Please, take another look |
|
test is now marked serial so it shouldn't have race issues w/ setting/unsetting the policy. /approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bparees, s1061123, zeeke 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 |
openshift-ci
Bot
added
the
approved
|
/retest-required |
2 similar comments
|
/retest-required |
|
/retest-required |
|
@zeeke: The following tests failed, say
Full PR test history. Your PR dashboard. 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/test-infra repository. I understand the commands that are listed here. |
|
/retest-required |
The MultiNetworkPolicy IPv6 test has been failing ~2-5% of the time since introduction in May 2023 due to incorrect IPv6 prefix length. IPv6 addresses use /32 (regional allocation size) instead of /64 (standard LAN subnet). This causes L2 adjacency to fail, preventing pod-to-pod communication over the macvlan secondary network. Root cause: - With /32: Kernel believes entire 2001:db8::/32 block is local - Routing gets confused about L2 adjacency - No Neighbor Discovery Protocol (NDP) attempted - Connection fails immediately (0 ms timeout) With /64 (this fix): - All pods in same 2001:db8::/64 subnet - NDP resolves MAC addresses - Direct macvlan L2 communication succeeds - Test proceeds to policy enforcement validation The IPv4 variant uses correct /24 prefix and has 100% pass rate. Sippy data (release 5.0): - IPv6 test: 97.95% pass (3 failures / 146 runs) - IPv4 test: 100% pass (0 failures / 142 runs) References: - Original PR (introduced bug): openshift#27795 - Restoration PR (restored with bug): openshift#27927 - Jira: OCPBUGS-6917, OCPBUGS-13788 Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
5 participants
Adding basic test cases to multinetwork policy feature.
This PR is mainly to avoid regressions like OCPBUGS-6917 from occurring again.