Bug 1619650 - Networkpolicy rules don't update reliably after a service restart
Summary: Networkpolicy rules don't update reliably after a service restart
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 3.7.1
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
: 3.7.z
Assignee: Dan Winship
QA Contact: Meng Bo
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-08-21 11:53 UTC by Sunil Choudhary
Modified: 2019-04-25 13:36 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1694704 (view as bug list)
Environment:
Last Closed: 2019-04-25 13:36:37 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Sunil Choudhary 2018-08-21 11:53:31 UTC
Description of problem:

After few days, the tcp-connections between newly created namespaces and already existing namespaces are failing, although the corresponding namespace-label  and network-policy is correctly applied. A recreation of the destination pod seems to solve the issue though.

This looks like a bug where the ovs-flow-table doesn't get updated reliably when a new namespace with a matching label gets deployed.

Version-Release number of selected component (if applicable):

OCP 3.7.42-1

How reproducible:

It is random and after few days.

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 7 Andreas Rother 2018-09-17 07:47:41 UTC
Any news about it?

Comment 8 Dan Winship 2018-09-19 17:28:33 UTC
Sorry there hasn't been any update here.

The sosreport doesn't reveal much more than what the reporter already figured out; for some reason, nodes are sometimes missing OVS flows that they ought to have. At default debug levels there isn't enough information logged to figure out why. We'll have to try to reproduce this locally.

Comment 10 Ben Bennett 2019-03-26 19:23:57 UTC
Weibin, can you please try to reproduce this?

Comment 12 Weibin Liang 2019-03-27 22:01:23 UTC
Dan,

Follow up your above steps, the final check failed in 3.7.70 but passed in 4.0.

Thanks for your detailed information.

Comment 14 Dan Winship 2019-04-25 13:36:37 UTC
fixed in master, and the customer case is closed


Note You need to log in before you can comment on or make changes to this bug.