-
Notifications
You must be signed in to change notification settings - Fork 4.8k
test/extended: Add MultiNetworkPolicy IPv4/IPv6 test cases #27795
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/extended: Add MultiNetworkPolicy IPv4/IPv6 test cases #27795
Conversation
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
| sdnDaemonset, err := oc.AdminKubeClient().AppsV1().DaemonSets("openshift-sdn").Get(context.Background(), "sdn", metav1.GetOptions{}) | |
| if err != nil { | |
| return false, nil | |
| } | |
| return sdnDaemonset.Status.NumberReady == sdnDaemonset.Status.NumberAvailable, nil |
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.
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()) |
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.
Ditto (check daemonset)?
|
/retest |
2 similar comments
|
/retest |
|
/retest |
|
|
||
| g.AfterEach(func() { | ||
| if !previousUseMultiNetworkPolicy { | ||
| disableMultiNetworkPolicy(oc) |
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
|
/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 |
Adding basic test cases to multinetwork policy feature.
This PR is mainly to avoid regressions like OCPBUGS-6917 from occurring again.