Only reschedule gateways/update segments when things have changed
that would require those actions.
This code has been cherry-picked from neutron:
https://review.opendev.org/#/c/705660
Co-Authored-By: Terry Wilson <twilson@redhat.com>
Conflicts:
networking_ovn/common/utils.py
networking_ovn/ovsdb/ovsdb_monitor.py
networking_ovn/tests/unit/l3/test_l3_ovn.py
networking_ovn/tests/unit/ovsdb/test_ovsdb_monitor.py
Change-Id: I62f53dbd862c0f38af4a1434d453e97c18777eb4
Closes-bug: #1861510
Closes-bug: #1861509
When Load Balancer and its member has FIP assigned
and environment is configured to use DVR the member
FIP needs to be centralized. It is current core OVN
limitation, that should be solved in [1].
This patch adds this mechanism to OVN Client.
It covers cases:
1) FIP association on port that is a member of
some LB - make it centralized.
2) FIP association on LB VIP - find a members
FIPs and centralized them.
3) The reverse of each of the above cases.
Related-Bug: #1860662
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1793897
Conflicts:
networking_ovn/common/ovn_client.py
networking_ovn/common/constants.py
networking_ovn/tests/unit/l3/test_l3_ovn.p
Change-Id: I254f0ac28f7585b699a8238e01ffb37dd70282ef
(cherry picked from commit 57ac38921e)
If a floating ip is associated to a port, it will be stored as
Logical_Switch_Port.external_ids:neutron:port_fip=FIP
OVN octavia driver will use this information to associate the floating ip
to the load balancer vip if the port is a virtual ip port created by
OVN octavia driver.
Signed-off-by: Numan Siddique <nusiddiq@redhat.com>
Co-Authored-By: Maciej Józefczyk <mjozefcz@redhat.com>
(cherry picked from commit c8e8cdbb4b)
Conflicts:
networking_ovn/tests/unit/fakes.py
Change-Id: Ia63a375e360fb7b1ee31e4d9f96b38d9f31f4096
This patch reverts [0].
The code wasn't accounting for VLAN provider networks, as stated in the
bug #1842988, DVR won't work if the provider network (where the FIP is
created) is VLAN.
There was also an incosistency in how the external_mac was set for the
VLAN networks. Upon creating the FIP the code was checking for the
network type and not setting the external_mac attribute in case the
network was VLAN type. But, if the port went down and up again (e.g if
you reboot the VM) the event handler that set/unset the external_mac [1]
wasn't check for the type. This is how people worked around the DVR
problem (as stated in bug #1842988).
For more information see bug #1842988.
[0]
c5aef51edc
[1]
eda5d7f80d/networking_ovn/ml2/mech_driver.py (L794-L800)
Closes-Bug: #1842988
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
(Cherry-picked from Neutron Ifb795626dc9c2ac4f0104f491dd38c9b4cc902c9)
Change-Id: I3e9e734b757f67d3e4ab1c5a02f8e7f9f0c9aa2e
(cherry picked from commit f9b1dffada)
For now while updating FIP check if port or logical_ip
has changed and only then we deleted the NAT entry.
Unfortunately each time when FIP update occurs the
method _create_or_update_floatingip() is used. It first deletes
LSP pointed by FIP and adds it again along with new NAT entries.
Based on author comment this actions are required.
So if we don't update FIP with logical_ip or new port_id,
like update a description, the NAT entries gets duplicated.
Since all is wrapped withing a transaction and to not wait for
proper fix (this code need sa refactor based on commments with NAT
external_id column) I think thats safe just to delete the NAT entry
in such situation like described above.
(cherry picked from commit 45ae9dfb7d5acacc72fcf9f071a9db1beb0ca972)
Change-Id: Iea532e2a02b7992305d1b90aa040e064901c340c
Related-Bug: #1859977
The following patch provides L3HA Rescheduling of gateways when chassis
are added/removed. It reschedules the gateway ports when a new chassis
is added/old one removed. However, the number of chassis where a
gateway can be hosted is limited by the constant MAX_GW_CHASSIS.
Co-Authored-By: Maciej Józefczyk <mjozefcz@redhat.com>
Conflicts:
networking_ovn/tests/functional/base.py
networking_ovn/tests/functional/test_router.py
networking_ovn/l3/l3_ovn_scheduler.py
Change-Id: I0d96efe4ceef4168039930738285c19d5c003951
Closes-Bug: #1762691
(cherry picked from commit 12070403db)
This patch is adding an external_id to the Logical_Router_Port
rows including the Neutron network ID.
The reason for this is that if we consume Octavia from Stein+ in
Rocky/Queens, this external id is missing and the OVN Octavia
driver (octavia_api) will not be able to apply the Load Balancers
to all the Logical Switches and Logical Routers where needed.
Note: This is a partial cherry-pick from
https://review.opendev.org/#/c/668397/ since Octavia itself
does not exist in stable/queens but can be made to work
with neutron's stable/queens.
Change-Id: I4a0614afda8d2c2b8ccbb2583bc339a232fc802e
Co-Authored-By: Daniel Alvarez <dalvarez@redhat.com>
Closes-Bug: #1855328
Related-Bug: #1794260
(cherry picked from commit aa4268a094)
Before this patch, the NAT rule was attempted to be updated when a
FIP was reassigned to another port. However, this was a noop
since the NAT rule didn't exist anymore causing the reassigning to
be ineffective and to fail silently.
This patch is always adding the NAT rule to the Logical Router
no matter if the Neutron FIP is being added or updated.
The bug that this patch addresses was being hit in the gate with
around a 30% ratio because the maintenance task was fixing it while
tempest was still rying to SSH into it.
Conflicts:
networking_ovn/common/ovn_client.py
Change-Id: Icebf4a82f64989112c3ca810b4358de490108c2d
Closes-Bug: #1835029
Closes-Bug: #1833820
Co-Authored-By: Jakub Libosvar <jlibosva@redhat.com>
Signed-off-by: Daniel Alvarez <dalvarez@redhat.com>
(cherry picked from commit d662f44428)
(cherry picked from commit 13689522d6)
(cherry picked from commit 9490a84f21)
When trying to use the Floating IP address of an instance
in a OVN-DVR setup while using VLAN tenant network type
the traffic does not pass. This is because of limitations
with VLAN tenant network types, which doesn't support
distributed VLAN routing.
The problem is the external_mac should not be set in the
NAT table for the Floating IP which belongs to the logical
port of a VLAN tenant logical switch. Otherwise, the compute
node which is binding the logical port will send the GARP
where as the routing for VLAN tenant networks is centralized.
Conflicts:
networking_ovn/tests/unit/l3/test_l3_ovn.py
Change-Id: I406204fc751387c02517286c87fe45533d70b93d
Closes-bug: #1828891
(cherry picked from commit c5aef51edc)
Prior to this patch, only IPv4 subnets were accounted to install
static routes on Logical Routers when setting a external gateway.
This is a problem if the public network has an IPv6 subnet as
instances won't get a default route.
Change-Id: I1cb4cd3dd2bf3be1e0beb4f2cc89a89fcf803f70
Closes-Bug: #1808753
Signed-off-by: Daniel Alvarez <dalvarez@redhat.com>
(cherry picked from commit 1c8da1eb83)
Presently IPv6 functionality is broken with OVN. When a VM
sends an IPv6 Neighbor Solicitation request for the router IP,
ovn-controller when it responds with Neighbor Adv packet doesn't
set the 'router' bit in the 'flags' field. This results in the
default route getting delted. The fix [1] tried to addressed this
issue. But that fix was not completely tested in the openstack context.
ovn-northd adds Neighbor Adv flows for router IPs both in the logical
switch pipeline and logical router pipeline. The commit [1] addressed
the issue in the logical router pipeline. It should have removed the
IPv6 Neighbor Adv flows from the logical switch pipeline. The patch [2]
has been proposed upstream to remove these flows from the logical
switch pipeline. Until that is fixed in core OVN, this patch addresses
this issue in networking-ovn itself as a temporary fix (with the intention
to backport as patch [2] may not be available for OVS 2.9).
When 'add_router_interface' is called, this patch sets the router ports
peer's Logical_Switch_Port.addresses column to it's mac address instead
of 'router'. If the Logical_Switch_Port.addresses is not set to 'router',
ovn-northd will not add the Neighbor Adv flows in the logical switch
pipeline, there by mitigating this issue.
Once the patch [2] is merged, we can revert these changes.
[1] - c9756229ed (diff-2c35162acf6ad144624954fdc4c3d9f4)
[2] - https://patchwork.ozlabs.org/patch/961565/
Closes-bug: #1788684
(cherry picked from commit 91d26e6573)
Conflicts:
networking_ovn/common/ovn_client.py
Change-Id: I815ce0996f66f6b101c2151a8389a8b3fbe026f6
When using distributed floating IPs, we set the external MAC
address and logical port fields regardless whether the LSP
is up. For the particular use of Octavia LB VIP, which doesn't
ever get bound, the floating IP associated to it will never
get the flows installed by ovn-controller.
This patch changes the mechanism so that the DNAT entries get
updated only on port up/down changes. If the port remains
down, the external_mac will be cleared and traffic to those
FIPs will still go through the centralized router.
When a port gets bound to a chassis, if DVR is enabled, the
mac_address field will be populated and traffic will go to
the compute node.
Conflicts:
networking_ovn/tests/unit/fakes.py
Closes-bug: #1789686
Change-Id: I0043984b4bb7b3780112aba170ffb956c48084d0
Signed-off-by: Daniel Alvarez <dalvarez@redhat.com>
(cherry picked from commit c44d075269)
This patch is fixing a problem which left the external/gateway's router
port with status DOWN even after the port was bound to a chassis.
Since the Logical_Router_Port table in OVNNB does not have a "up" column
(like the Logical_Switch_Port table has) the status of those ports can
not be updpated based on it. Therefore, this patch uses the "chassis"
column for that. If the router port has the "chassis" column in OVNNB
database set, the binding and status ACTIVE will be set in Neutron
otherwise it status will be udpated to DOWN (if it's not DOWN yet).
Closes-Bug: #1715126
Change-Id: I91026204eae6df18be47df02f99db2f95c428e2b
(cherry picked from commit 3d575d19b8)
This patch consolidades the database transactions for creating/deleting
router ports on/from the OVN NB database. Having a single transaction is
ideal to avoid inconsistencies that can be cause between two or more
transactions.
Closes-Bug: #1756388
Change-Id: I0a0a5f6571ea695b91db89170be1fab258acd917
(cherry picked from commit 378f4ec58e)
Admin sets ovn-cms-options in external_ids as
ovs-vsctl set open .
external_ids:ovn-cms-options="enable-chassis-as-gw"
to enable a chassis as a candidate for scheduling gateway router.
Networking-ovn will parse ovn-cms-options and select this chassis
if it has proper bridge mappings.
This helps admin to exclude compute nodes to host gateway routers as
they are more likely to be restarted for maintenance operations.
We follow this order for selecting candidates
1) candidates with ovn-cms-options and proper bridge mappings
2) if no candidates from 1), then chassis with proper
bridge mappings
Conflicts:
doc/source/admin/refarch/refarch.rst
Closes-bug: #1743745
Change-Id: I86fbe27f0b6a9317ad82c2bcf2a0446d118de35b
This past checks correctness when adding, removing router
interfaces, updating them, or managing the router gateway port.
For router ports, every resource (port) on the neutron side,
becomes two on the ovn side. This is why we introduce a new
type of resource to be tracked ROUTER_PORTS, and we also track
them as standard L2 PORTS.
The ROUTER_PORT resources handle the creation and update of
Logical_Router_Port and NAT resources (always going on the
same transactions).
Change-Id: I96a7e812427ebbc8e868a0e3ab78754084cdaecf
Now the port AFTER_UPDATE event is captured on the l3_ovn plugin,
and we make sure that it will succeed even if the router port
is still not created (which is a normal condition during initial
port create inside l3 because neutron router port creation
calls update before the flow continues to OVN L3 plugin, and
it's able to create the LRP).
Change-Id: I2a695ffc2ece23c9c3658511a9b2b03d4d3d15ef
Closes-Bug: 1745343
This patch is updating networking-ovn to check for correctness when
creating, updating or deleting floating ips.
Partial-Bug: #1605089
Change-Id: I377007c955809b8d56af93e24f0914e446f56bb2
This patch is updating networking-ovn to check for correctness when
creating, updating or deleting routers.
Partial-Bug: #1605089
Change-Id: Ida7e6100071a1e484927ca9638702e438918937a
This patch is refactoring the routers resource to adhere with the
database sync specification.
The update_router() method from OVNClient has been modified to not
depend on the "original_router" parameter anymore. A layer to make it
backward compatible with existing routers and OVS version < 2.8.2 was
added as well.
Partial-Bug: #1605089
Change-Id: I1744c91004fc36e0b97ebc51230f876eaaa3bd7f
This commit [0] added the external_ids column to the NAT table
in OVN NB database. As it's not yet included in any OVS release,
this patch checks for the column existence before writing data
into it. Since the existing code is backwards compatible, it
will still work without that column.
Once we're sure that the minimum required OVS version contains this
column, we can revert this patch.
[0] c4c1e1a5af
Change-Id: I907ce96d2e7b99ff01646a929ac5f60a9150e52f
Signed-off-by: Daniel Alvarez <dalvarez@redhat.com>
OVN supports Router Solicitation responder i.e it will reply to the
Router Solicitation packets. In order to use this feature, we need
to configure the Logical_Router_Port.ipv6_ra_configs column with the
appropriate values. This patch does that. When a router is added with
an interface port, these values are added.
Support to send periodic Router Advertisement in OVN is under review.
This patch also configures to use this feature by setting
Logical_Router_Port.ipv6_ra_configs:send_periodic='true'. There is no harm
in setting this in this patch.
Change-Id: I5d4d16e517d71830ea16245529dd2ba5433e0fd3
This patch is bringing logic for handling floating ips out of the L3
driver and into OVNClient.
The code now uses the ``external_ids`` column in the NAT table from
OVNDB to bind the FIP from Neutron DB with it (before we used a
combination of external + logical ips to identify those entries).
The values added in the ``external_ids`` are:
* neutron:fip_id = The ID of the FIP in neutron
* neutron:fip_port_id: This is used in the update_floatingips() method
to compare and see whether the port_id of the FIP has changed in the
update or not.
* neutron:router_name: The name of the router which the FIP is associated
with.
The ovn_db_sync.py script was updated to make use the updated methods
in OVNClient to create and delete floating IPs, that way we avoid the
code duplication that existed between this script and the L3 driver.
Partial-Bug: #1605089
Change-Id: I21e9728c93392de4c579ea00c34059ad6812f682
After patch[1] merged, multiple routes commands can be consolidated in
one transaction. This patch optimize _subnet_update for it.
This patch also adds some comments to test case because it's difficult
to find its relevant test cases without comments.
[1]https://review.openstack.org/#/c/515673/
Change-Id: Idb51a347ba76b3e449939721a4abc0184f915459
Signed-off-by: Dong Jun <dongj@dtdream.com>
This patch is modifying the update_router() method - and all the related
methods - to consolidade all commands into a single transaction.
This ensures consistency when updating the router resource since now all
changes to OVSDB are chained.
Change-Id: Ic06bdfcdc0f871e925e5a957ff29c290072bd02c
User can enable the distributed floating ip by configuring the
option enable_distributed_floating_ip.
This require the user to configure the physical network map
to connecting the floating ip's network on each compute node.
the Nat action for floating IP will be done locally, not
gateway. This will saves the path to the external network.
Change-Id: I4e8d6811b5a544e68b184fe457391b35e4516d01
Co-authored-by: Dong Jun <dongj@dtdream.com>
This patch is moving some of the logic from the {create,
update}_router() methods of the L3 driver into the OVNClient. In
summary, two things is being done in this patch:
* Remove the "networks" parameter from the {create, update}_router()
method in OVNClient. Now the list of network is fetched within these
methods.
* Remove the "delta" parameter from the update_router() method in
OVNClient. We are already passing the new and old version of the
router to that method, we know the differences we don't need to have
an extra parameter for it.
This patch is related to the work to that is being done at bug #1605089
which uses the OVNClient to recovery the resources that are out of sync
and by having OVNClient to handle the bulky work does simplify the
synchronization work.
Related-Bug: #1605089
Change-Id: I8f0afb841e042f75e5062cca81717a3ecad17015
Commit [0] supported garp feature and added an optional arg is_gw_port,
it's nicer for caller to pass arg name to set_lrouter_port_in_lswitch_port.
This patch does this and adds missing asserts to related unit tests.
[0]https://review.openstack.org/#/c/506547/
Change-Id: I0ec18da3351e700507d246169e7bf41cf924a87c
Signed-off-by: Dong Jun <dongj@dtdream.com>
This is used to send gratuitous ARPs for SNAT and DNAT IP addresses on gateway port via the localnet port.
Change-Id: Ic16f58a4885e1327f011828fd728a6fa197d8efc
This patch is first step towards supporting internal DNS support by
making use of OVN native DNS feature. This patch for now just adds
the DNS db mixin to resolve the bug 1714931. Without this patch, creating
floating ip is failing with 500 error when dns extension is enabled.
There were some unit test failures because of neutron db code accessing
'dns' data of floatingip db object as 'floatingip_db.dns'.
Neutron code references the db objects both as a dict and as an object.
Eg. port['id'] and port.id. This patch makes the FakeResource object
as a dict to fix this issue.
Closes-bug: #1714931
Change-Id: Id8f2c1216e6187bf95fea660c83a1d41aeefbb86
Currently ovn schedules gateway router ports on all chassis.
Instead we need to check which chassis has external connectivity
and schedule them only on these chassis.
Chassis which has ovn-bridge-mappings properly configured(i.e
physnet same as gateway network physnet) in OVN_Southbound
database will be treated as having external connectivity.
Some network types(for example, geneve) may not use bridge
mappings. Currently, external networks of type VLAN and FLAT
use bridge mappings. So for these networks, we return chassis
with proper bridge mappings and for other networks we return
all chassis.
Closes-bug: #1705246
Change-Id: I73970aef6d84019032e3c68a6a785d7626ae2afc
Recently L3 gateway HA support added in OVN making
distributed gateway ports highly available. This
patch makes neutron gateway ports highly available
through OVN distributed gateway ports.
If multiple gateway chassis available for scheduling as candidates,
then this patch schedules router gateway port on max of 5 chassis.
If only one gateway chassis is available, it schedules on only this
chassis.
If NBDB supports new schema to represent gateway_chassis i.e
1) gateway_chassis column in logical_router_port table
2) and Gateway_Chassis table
router gateway port is scheduled based on this new schema, otherwise old
schema is used. If existing router gateway ports are already using old
schema, this patch still supports that and won't convert them to new
schema.
Change-Id: I56c28237b19a6ae01f8567d12580661bcca43ba7
The well known service type constants are in
neutron_lib.plugins.constants, but for legacy reasons a few still exist
and are referenced from neutron_lib.constants [1] that we'd like to
remove.
This patch switches references over to neutron_lib's plugin constants.
[1] https://github.com/openstack/neutron-lib/blob/master/neutron_lib/constants.py#L353
Change-Id: I8b5141f952b3500c7a4ce9c36e07a04630a5e44f
Right now we have code doing CRUD operations on ONV resources spread
around different places (ml2/mech_driver.py, l3/l3_ovn.py), this makes
things very complicated to implement something like journaling (see
bug: #1605089) where all resources, L2 and L3, are created from a
central place (the journal thread, which keeps things in order).
This patch is adding a new class called OVNClient which centralizes all
the CRUD operations for the OVN resources in one place.
For this first iteraction, the Port resource from the mechanism driver
and the L3 resources (floating ip, routers and routers ports) are being
moved to this new class, others will come in follow up patches.
Related-Bug: #1605089
Change-Id: Ia453a14cdc2ec393037fb813caff8fae23acd7c3
This patch fixes intermittent failure of two unit test cases,
test_enable_snat and test_disable_snat.
The reason is, str(dict) has a stable output in python 2 rather than in
python 3. I copy the checking logic from _check_for_external_ip_change
Change-Id: I3b532e875906d38d2d4f4ffb85ba4fb7886dfa7b
Partial-Bug: #1685844
Signed-off-by: Dong Jun <dongj@dtdream.com>
This patch is an attempt to fix up the race condition we have seem in
the L3 unit tests. This patch does two things:
* We make sure that all mocks that are started at the setUp() method are
also stopped (self.addCleanup)
* Remove the name collision with the "l3_plugin" attribute in the test
class. The base class already contains a class attribute called
"l3_plugin" which holds a path (string) as the value but it was being
overritten in the setUp() method with an instance of the L3 plugin.
Change-Id: I2c25bd0c31958c0ea769f53b88d6dcc92669a630
Partial-Bug: #1685844
Adapt new QoS driver to fix devstack failure.
Override test_floatingip_update_subnet_gateway_disabled to fix unit
test.
Change mapping_dict.keys() to list(mapping_dict.keys()) in
_get_chassis_physnets to fix python3.5 dsvm functional test
Closes-Bug: #1683722
Closes-Bug: #1659821
Change-Id: Ic51ca5e396a34197cdc60844a9eaaa605041ccc5
When VM with floating IP associated was deleted, dnat_and_snat row in
OVN_Northbound DB was not removed. Then delete this floating IP,
dnat_and_snat is still in OVN DB.
Currently a workaround in _update_floating_ip_in_ovn is, when
re-associating, getting the list of nat rules and checking if the
external_ip with type 'dnat_and_snat' already exists or not. If exists,
set the new value.
However, disassociate_floatingips is the conventional approach for
l3 plugin to handle the callback of VM port' deleting, this patch
implements the function in l3_ovn plugin.
Change-Id: Ib487c00905d08e1f47f77bd4ddb2810c8ee19ea9
Closes-Bug: #1677581
Signed-off-by: Dong Jun <dongj@dtdream.com>
These three written errors of assert_called_once_with make their
asserts ignored.
Change-Id: I4de15805b5b23605cf777cae5853231883ced1b4
Signed-off-by: Dong Jun <dongj@dtdream.com>
If try to update extra attributes, such as description, the floating
IP nat rules will be removed from OVN DBs once, which is unnecessary
and causing connection lose.
This patch will make the floating IP association status check more
specific.
Change-Id: Ia0fb12fdc34893c6ab0defa67007dc51d0f6e7d6
Closes-Bug: #1662405
Zuul