Bug 1394894 - Compute and controller nodes are not reachable after reboot when OVS bridges are set to secure fail mode
Summary: Compute and controller nodes are not reachable after reboot when OVS bridges ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron
Version: 8.0 (Liberty)
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: async
: 8.0 (Liberty)
Assignee: Miguel Angel Ajo
QA Contact: Toni Freger
URL:
Whiteboard:
: 1397557 (view as bug list)
Depends On: 1386299 1394890
Blocks: 1391031
TreeView+ depends on / blocked
 
Reported: 2016-11-14 16:25 UTC by Miguel Angel Ajo
Modified: 2020-12-14 07:52 UTC (History)
45 users (show)

Fixed In Version: openstack-neutron-7.2.0-3.el7ost
Doc Type: No Doc Update
Doc Text:
undefined
Clone Of: 1394890
Environment:
Last Closed: 2016-12-21 16:46:27 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
OpenStack gerrit 395854 0 None None None 2016-11-14 16:25:17 UTC
Red Hat Knowledge Base (Solution) 2746071 0 None None None 2016-12-22 19:46:20 UTC
Red Hat Product Errata RHBA-2016:2988 0 normal SHIPPED_LIVE openstack-neutron bug fix advisory 2016-12-21 21:35:02 UTC

Comment 3 Miguel Angel Ajo 2016-11-15 15:05:35 UTC
To test this, check any provider network bridge after update, and make sure it's set as "standalone"

For example, if you have br-ex

# ovs-vsctl get-fail-mode br-ex
standalone

Comment 4 Randy Perryman 2016-11-18 15:59:48 UTC
Need the update OpenStack gerrit review number.

Comment 6 Assaf Muller 2016-11-22 22:37:33 UTC
*** Bug 1397557 has been marked as a duplicate of this bug. ***

Comment 7 Andreas Karis 2016-11-23 18:00:43 UTC
Note that this bug is affecting OSP 9 as well:

~~~
[root@overcloud-controller-0 ~]# ovs-vsctl get-fail-mode br-ex
secure
[root@overcloud-controller-0 ~]# ovs-ofctl dump-flows br-ex
NXST_FLOW reply (xid=0x4):
~~~

~~~
[root@overcloud-controller-0 ~]# rpm -qa | grep neutron
openstack-neutron-bigswitch-lldp-2015.3.8-1.el7ost.noarch
openstack-neutron-ml2-8.1.2-5.el7ost.noarch
openstack-neutron-common-8.1.2-5.el7ost.noarch
openstack-neutron-lbaas-8.0.0-1.el7ost.noarch
python-neutron-lbaas-8.0.0-1.el7ost.noarch
openstack-neutron-openvswitch-8.1.2-5.el7ost.noarch
openstack-neutron-metering-agent-8.1.2-5.el7ost.noarch
python-neutronclient-4.1.1-2.el7ost.noarch
python-neutron-lib-0.0.2-1.el7ost.noarch
openstack-neutron-bigswitch-agent-2015.3.8-1.el7ost.noarch
python-neutron-8.1.2-5.el7ost.noarch
openstack-neutron-8.1.2-5.el7ost.noarch
~~~

~~~
[root@overcloud-controller-0 ~]# rpm -q --changelog openstack-neutron-8.1.2-5.el7ost.noarch | head
* Wed Sep 14 2016 Hynek Mlnarik <hmlnarik> 1:8.1.2-5
- Set secure fail mode for physical bridges, rhbz#1372369
- Pass timeout in milliseconds to timer_wait, rhbz#1366187
~~~

Do we already have a fix or BZ for OSP 9?

Comment 8 Assaf Muller 2016-11-23 18:05:48 UTC
Yes, please see https://bugzilla.redhat.com/show_bug.cgi?id=1394890, found via this bug's dependency chain.

Comment 10 Toni Freger 2016-11-24 13:46:18 UTC
Verified on latest version openstack-neutron-7.2.0-5.el7ost.noarch

According to following steps:

1) check   <provider-net-bridge> ( br-ex) in standalone mode :
2) set the bridge to secure manually:

     sudo ovs-vsctl set-fail-mode <provider-net-bridge> secure
3) sudo service neutron-openvswitch-agent restart

4) check that it's gone back to standalone:

Comment 11 Randy Perryman 2016-12-06 21:01:23 UTC
Will this be fixed in OSP 8??

Comment 12 Randy Perryman 2016-12-06 21:01:38 UTC
Will this be fixed in OSP 8??

Comment 13 Andreas Karis 2016-12-06 21:05:21 UTC
Hello,

Yes, this bug tracker is for OSP 8 and it will be fixed in versions >= openstack-neutron-7.2.0-3.el7ost   (see the fields in the header section of this bugtracker)

Comment 14 Mike Burns 2016-12-06 21:50:55 UTC
Yes, this is targeted for our next update of osp 8.

Comment 16 errata-xmlrpc 2016-12-21 16:46:27 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.

https://rhn.redhat.com/errata/RHBA-2016-2988.html


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