Bug 1821986
Summary: | No new ovs flows add to table 80 after restart sdn pod and create a allow-all networkpolicy | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Ross Brattain <rbrattai> |
Component: | Networking | Assignee: | Juan Luis de Sousa-Valadas <jdesousa> |
Networking sub component: | openshift-sdn | QA Contact: | Ross Brattain <rbrattai> |
Status: | CLOSED WONTFIX | Docs Contact: | |
Severity: | low | ||
Priority: | low | CC: | anbhat, bbennett, huirwang, jdesousa, vcojot |
Version: | 4.4 | ||
Target Milestone: | --- | ||
Target Release: | 4.6.0 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | SDN-QA-IMPACT | ||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | 1790440 | Environment: | |
Last Closed: | 2020-09-10 15:08:53 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1790440 | ||
Bug Blocks: | 1790407, 1790805, 1793952 |
Description
Ross Brattain
2020-04-08 02:29:53 UTC
> Frequently using automation, difficult using manual steps
I suspect this may be related to the rule being created while the SDN pod is stopped.
Can you add a 30 second sleep to the automated test between the sdn pod being deleted and the allow-all rule being created, and launch the test a bunch of times and see if it reproduces that way please?
I added a "wait for SDN pod ready" step to the automation and that seems to have fixed the issue. I'm not sure what the synchronization expectation is if the networkpolicy is created when not all the SDN pods are ready. Note: it seems to only take ~15 seconds for the SDN pod to be ready. [16:32:11] INFO> Shell Commands: oc delete pods sdn-582sr --wait=false --namespace=openshift-sdn [16:32:26] INFO> Shell Commands: oc create -f features/tierN/testdata/networking/networkpolicy/allow-all.yaml networkpolicy.networking.k8s.io/allow-all created Hi Ross, I see this is in the errata, but I don't think this should be published in an errata at all. Can you remove it please? This isn't really solved, although I think it's fine to wait for the SDN pod to be recreated and leave this open in a lower priority. Or even close it with a WONTFIX, but definitely not verified. This is an extreme corner case. This happens only in the following conditions: 1- There is a deny-all networkpolicy without any allow policy at all. 2- The SDN pod stops for whatever reason 3- Before the SDN pod starts again, someone creates an allow-all rule. Must be an allow-all, a rule allowing specific ports, or a subset of pods in the namespace won't trigger this. This is a incredibly specific corner case... and I don't think anyone will ever hit it. But nevertheless it's still not fixed and shouldn't be verified. Thanks! hi, Juan IMO, this iisue happen since the SDN pod has not be working well totally. so the networkpolicy has not be working as expected. I think this can be accepted since the policy will take effect after the sdn pod started totally. Sorry for the verified, I'm still learning the BZ workflows. I agree this is still an issue. When creating network policies, customer shouldn't have to wait 30 seconds or wait for any particular SDN pods to be ready, once network policy is created it should be implemented correctly. Zhanqi, it's not worth the effort since it's an edge case and it's almost impossible to hit in real life. If a customer actually hits this we'll fix it, but I find that extremely unlikely. |