Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1433532 - (ovnl3ha) [RFE] [Neutron] [OVN] L3 HA
[RFE] [Neutron] [OVN] L3 HA
Status: CLOSED ERRATA
Product: Red Hat OpenStack
Classification: Red Hat
Component: openvswitch (Show other bugs)
12.0 (Pike)
Unspecified Unspecified
high Severity high
: Upstream M2
: 13.0 (Queens)
Assigned To: Miguel Angel Ajo
Eran Kuris
: FutureFeature, Triaged
: 1498109 (view as bug list)
Depends On:
Blocks: osp13ovn 1548947
  Show dependency treegraph
 
Reported: 2017-03-17 19:09 EDT by Assaf Muller
Modified: 2018-06-27 09:30 EDT (History)
11 users (show)

See Also:
Fixed In Version: openvswitch-2.9.0-3.el7fdb
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-06-27 09:29:18 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2018:2086 None None None 2018-06-27 09:30 EDT

  None (edit)
Description Assaf Muller 2017-03-17 19:09:38 EDT
OVN L3 is currently a single point of failure and it should be highly available.
Comment 3 Miguel Angel Ajo 2017-04-24 09:15:30 EDT
Discussing up with the community
https://mail.openvswitch.org/pipermail/ovs-dev/2017-April/330597.html

And talking about limitations of the planned approach to do L3 HA Active/Standby, which are also present on VRRP or other protocols.
https://mail.openvswitch.org/pipermail/ovs-dev/2017-April/330597.html
Comment 4 Assaf Muller 2017-04-24 09:28:12 EDT
This will require OVS 2.8, pushed to OSP 13.
Comment 5 Miguel Angel Ajo 2017-07-17 11:50:27 EDT
ovn-core patches merged, now we need to work on the networking-ovn side.
Comment 7 Nir Yechiel 2017-10-03 11:00:29 EDT
An idea we just discussed was extending the northbound database with a simple boolean on the Gateway_Chassis table to reflect if it's the current master or not.  That information is already available through the southbound database by examining the Port_Binding table, but doing something in the northbound db would be a usability improvement.

One catch is that the current db schema allows you to reference a single Gateway_Chassis for multiple gateways, so maybe putting the column on Gateway_Chassis doesn't work.  Another option could be a new column on Logical_Router_Port that references a single gateway_chassis row to indicate which is the current master.
Comment 8 Nir Yechiel 2017-10-03 11:00:44 EDT
*** Bug 1498109 has been marked as a duplicate of this bug. ***
Comment 12 Eran Kuris 2018-04-10 02:34:08 EDT
verified on OSP13 puddle 2018-04-03.3
openvswitch-2.9.0-15.el7fdp.x86_64

there are some bugs. All the results updated in test run:

https://polarion.engineering.redhat.com/polarion/#/project/RHELOpenStackPlatform/testrun?id=20180327-1217
Comment 14 errata-xmlrpc 2018-06-27 09:29:18 EDT
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://access.redhat.com/errata/RHEA-2018:2086

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