Bug 1552002

Summary: neutron: Call destroy-patch-ports before starting ovs-agent
Product: Red Hat OpenStack Reporter: Marian Krcmarik <mkrcmari>
Component: openstack-tripleo-heat-templatesAssignee: Jakub Libosvar <jlibosva>
Status: CLOSED ERRATA QA Contact: Gurenko Alex <agurenko>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 13.0 (Queens)CC: aschultz, bcafarel, jlibosva, jschluet, mburns, rhel-osp-director-maint, ushkalim
Target Milestone: betaKeywords: AutomationBlocker, Triaged
Target Release: 13.0 (Queens)   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: openstack-tripleo-heat-templates-8.0.0-0.20180304031146.6cd4184.el7ost Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-06-27 13:46:51 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

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.