Bug 1552002 - neutron: Call destroy-patch-ports before starting ovs-agent
Summary: neutron: Call destroy-patch-ports before starting ovs-agent
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-heat-templates
Version: 13.0 (Queens)
Hardware: Unspecified
OS: Unspecified
Target Milestone: beta
: 13.0 (Queens)
Assignee: Jakub Libosvar
QA Contact: Gurenko Alex
Depends On:
TreeView+ depends on / blocked
Reported: 2018-03-06 10:14 UTC by Marian Krcmarik
Modified: 2018-06-27 13:48 UTC (History)
7 users (show)

Fixed In Version: openstack-tripleo-heat-templates-8.0.0-0.20180304031146.6cd4184.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-06-27 13:46:51 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
OpenStack gerrit 519354 None master: MERGED tripleo-heat-templates: neutron: Call destroy-patch-ports before starting ovs-agent (I005af23b1815c904ef63676553df9b14b7... 2018-03-15 18:03:36 UTC
OpenStack gerrit 553275 None stable/queens: NEW tripleo-heat-templates: neutron: Call destroy-patch-ports before starting ovs-agent (I005af23b1815c904ef63676553df9b14b7... 2018-03-15 18:03:29 UTC
Red Hat Product Errata RHEA-2018:2086 None None None 2018-06-27 13:48:04 UTC

Description Marian Krcmarik 2018-03-06 10:14:22 UTC
Description of problem:
From https://review.openstack.org/#/c/519354/:
The script called destroy-patch-ports will break connection between the integration bridge and provider bridges configured in Neutron config files. See https://bugzilla.redhat.com/show_bug.cgi?id=1490281 for more details about the reason. With systemd, we have control over dependencies between services, therefore we can tell that destroy-patch-ports service must be run before neutron-openvswitch-agent. But we do not have this ability using docker. That's why this patch simply calls the script before each start of the agent. To avoid unnecessary breakage of patch ports, the script was enhanced to check a canary flow on integration bridge and in case the flow is there, it will not delete the patch ports. Presence of canary flow on integration bridge means that bridge has been already configured. It also implies provider bridges are configured too and thus they can't cause the ARP storm as described in Red Hat Bugzilla 1490281.

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

How reproducible:

Steps to Reproduce:
1. reboot all controllers at once
2. wait for them to come back online

Actual results:
ARP Storm at controllers

Expected results:
No network issues

Additional info:

Comment 4 errata-xmlrpc 2018-06-27 13:46:51 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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