Commit Graph

5351 Commits

Author SHA1 Message Date
Rodolfo Alonso Hernandez 70ddf4eef5 Add "socket" NUMA affinity policy
This new extension adds a new parameter to the NUMA affinity policy
list: "socket". The "socket" NUMA affinity policy has been supported
in Nova since [1].

[1]https://review.opendev.org/c/openstack/nova/+/773792

Closes-Bug: #2052786
Change-Id: Iad2d4c461a2aceef6ed2d5e622cce38362d79687
2024-03-21 16:04:24 +00:00
Zuul 95e4e3b092 Merge "Use oslo_service's SignalHandler for signals" 2024-03-20 00:21:51 +00:00
Rodolfo Alonso Hernandez 0fd654f592 [OVN] Use the LSP update event to update the LRP
Now the "Logical_Router_Port" is updated when a "Logical_Switch_Port"
event is received. When the event is received, it is first checked that
the "Logical_Switch_Port" belongs to a router; if that check is
possitive, the router port update method is called.

Closes-Bug: #2056558
Change-Id: I13b4c804ea6a9f8a89d3796c1cec88ffa1de6ded
2024-03-10 04:39:40 +00:00
Rodolfo Alonso Hernandez f82c650c8c [OVN] Add the network type to the ``Logical_Switch`` register
Now the ``Logical_Switch`` register (that represents an OVN network),
stored the network type in the "external_ids" field.

Related-Bug: #2056558
Change-Id: I9e55a7412d841b7b59602c56c3a4e2f9c954aeed
2024-03-13 07:38:03 +00:00
Terry Wilson a4e49b6b8f Use oslo_service's SignalHandler for signals
When Neutron is killed with SIGTERM (like via systemctl), when using
ML2/OVN neutron workers do not exit and instead are eventually killed
with SIGKILL when the graceful timeout is reached (often around 1
minute).

This is happening due to the signal handlers for SIGTERM. There are
multiple issues.

1) oslo_service, ml2/ovn mech_driver, and ml2/ovo_rpc.py all call
   signal.signal(signal.SIGTERM, ...) overwriting each others signal
   handlers.
2) SIGTERM is handled in the main thread, and running blocking code
   there causes AssertionErrors in eventlet which also prevents the
   process from exiting.
3) The ml2/ovn cleanup code doesn't cause the process to end, so it
   interrupts the killing of the process.

oslo_service has a singleton SignalHandler class that solves all of
these issues

Closes-Bug: #2056366
Depends-On: https://review.opendev.org/c/openstack/oslo.service/+/911627
Change-Id: I730a12746bceaa744c658854e38439420efc4629
Signed-off-by: Terry Wilson <twilson@redhat.com>
2024-03-06 23:20:07 +00:00
Zuul c4c14f9589 Merge "[OVN] Set MTU of the VETH interfaces between OVS and metadata" 2024-03-05 09:48:42 +00:00
Rodolfo Alonso Hernandez b5aecfeff8 [OVN] Make mandatory the router name in the LRP.external_ids
The router name will be always defined in the "Logical_Router_Port"
external_ids field.

Related-Bug: #2052821
Change-Id: Ia2f70363963dca9f035eff8d1ff0c399dc8b9239
2024-03-04 08:10:48 +00:00
Zuul 310a96a302 Merge "[ovn] Add support for enable_default_route_bfd attribute" 2024-03-01 23:04:54 +00:00
Zuul afe001cf63 Merge "[OVN] Remove OVN_GATEWAY_INVALID_CHASSIS artifact" 2024-03-01 20:38:48 +00:00
Zuul fffcab9f68 Merge "[ovn] Ensure OVN DB update on change of number of GW ports" 2024-03-01 12:43:55 +00:00
Zuul 44159ca659 Merge "[OVN] Identify the LR GW port with "external_ids:neutron:is_ext_gw"" 2024-03-01 07:53:15 +00:00
Rodolfo Alonso Hernandez fa3223bb9d [OVN] Remove OVN_GATEWAY_INVALID_CHASSIS artifact
This artifact is no longer used in the "Logical_Router" registers (in
the "options" field) to mark this "Logical_Router" as unhosted. A
"Logical_Router" is considered as unhosted if the gateway
"Logical_Router_Ports" have no "chassis" set.

This artifact is also used to create a "Gateway_Chassis" register
pointing to a inexisting invalid chassis called
"neutron-ovn-invalid-chassis". Any "Logical_Router_Port" not bound
to a chassis will have no value in "gateway_chassis" (NOTE1).

NOTE1: this is valid now with the current two OVN L3 schedulers that
use "gateway_chassis" to schedule the "Logical_Router_Port" of a
router. In a future, we can consider using "ha_chassis_group" for
scheduling.

Partial-Bug: #2052821
Related-Bug: #2019217
Change-Id: I12717936fe2bc188545309bacb8a260981f14c88
2024-03-01 07:03:26 +00:00
Frode Nordahl cc1ff09b9e
[ovn] Add support for enable_default_route_bfd attribute
When ``enable_default_route_bfd`` is set, maintain BFD records
along with default route records.  Default route records will
also be fitted with the `output_port` key, which is a requirement
for the OVN BFD support.

Partial-Bug: #2002687
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Change-Id: I34e2453ab206c13c3ca40c4181970c320bdd8e67
2024-02-29 22:01:06 +01:00
Frode Nordahl 743bd1ccef
[ovn] Ensure OVN DB update on change of number of GW ports
If a router is created and a GW port is subsequently added by
updating the router, the change is not always propagated to the
OVN DB.

This patch fixes this and also adds a functional test case.

Trivial-Fix
Partial-Bug: #2002687
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Change-Id: I9455678d73fb35b77eac7416917200a419abfa84
2024-02-29 11:54:13 +01:00
Frode Nordahl ae9749a5e3
[ovn] Ensure all routes are deleted when deleting ExtGw
The current DeleteLRouterExtGwCommand stops iterating over static
routes once the first route with a ovn_const.OVN_ROUTER_IS_EXT_GW
external_id is found.

There can be multiple static routes with this external ID, so
this patch continues iteration until all external routes are
removed and adds a unit test for this condition.

Trivial-Fix
Partial-Bug: #2002687
Change-Id: Ie43abd8bf511e12a0f64c10bafeaafc0823a2076
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
2024-02-29 11:54:13 +01:00
Frode Nordahl 8df5ee61d9
[ovn] Apply soft anti-affinity for LRs with multiple LRPs when scheduling
Move scheduling logic from OVNClient._create_lrouter_port to an
ovsdbapp command so that scheduling decisions are made on up to
date information as the transaction applies.

One of the main use cases for routers with multiple gateway
ports are resiliency.  Whenever there are multiple LRPs present in
a LR, we want to ensure diverse placement of the ports to
minimize impact of chassis failure.

Partial-Bug: #2002687
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Change-Id: I36860b739a8cb99ba0e7fc65950ea252ad6803c4
2024-02-27 11:06:08 +01:00
Frode Nordahl 898498ca3b
[ovn] Add helper for retrieving LR associated with LRP
This will be used in the next patch set to implement anti-affinity
scheduling for routers with multiple LRPs.

Partial-Bug: #2002687
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Change-Id: Iff958195f229f7e0714f1285bb3d53497aeec9aa
2024-02-27 11:06:08 +01:00
Frode Nordahl 0bae4b70b6
[ovn] Make scheduling of unhosted gateways aware of current transaction
At present, whenever multiple additions/updates are made to LRPs
with gateway_chassis, each update is put in separate transactions
in an attempt to ensure the scheduler operates on updated
information for each iteration.

This is problematic because we don't have the luxury of creating
separate transactions for updates in all parts of the code base,
and it is also not very efficient.

The OVSDBapp library wraps the OVS Python IDL and provides
different semantics. Most notably the OVSDBapp represents a
Transaction as a list of command objects with `run_idl` methods
for execution at some point in the future. The main loop and the
command objects are not aware of changes made in the current
transaction until it is committed.

Fortunately, as an ovsdbapp transaction is committed, the
underlying OVS Python IDL is kept up to date during the course of
the transaction [0][1][2].

Move implementation of scheduling of unhosted gateways into an
ovsdbapp command, using a plugin reference to the Neutron
OVNClient class for any calls into the Neutron code, allowing
scheduling decisions to be made on up to date data as the
transaction is applied.

0: https://github.com/openvswitch/ovs/blob/e3ba0be48ca4/python/ovs/db/idl.py#L1316
1: https://github.com/openvswitch/ovs/blob/e3ba0be48ca4/python/ovs/db/idl.py#L1400
2: https://github.com/openvswitch/ovs/blob/e3ba0be48ca4/python/ovs/db/idl.py#L2083

Partial-Bug: #2002687
Co-Authored-By: Terry Wilson <twilson@redhat.com>
Co-Authored-By: Brian Haley <haleyb.dev@gmail.com>
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Change-Id: I83bcf7fe838c0d6b0617c43439643e8443b2bdae
2024-02-27 11:06:01 +01:00
Rodolfo Alonso Hernandez 47b4d14955 [OVN] Set MTU of the VETH interfaces between OVS and metadata
The VETH pair between the metadata namespace and the local OVS now
has the same MTU as the network associated to this metadata service.
The "LSP.external_ids" field has a new key defined: "neutron:mtu".
This is the value of the network MTU.

This patch does not update the previous metadata datapaths nor the
existing LSP. This change will affect only to new created ports
and the corresponding metadata datapaths.

Closes-Bug: #2053274

Change-Id: I7ff300e9634e5e3fc68d70540392109fd8b9babc
2024-02-25 09:38:50 +00:00
Rodolfo Alonso Hernandez f73a2515cb [OVN] Identify the LR GW port with "external_ids:neutron:is_ext_gw"
Since [1], any "Logical_Router_Port" has a key in "external_ids" to
identify if it is an external gateway or not. This key is
"neutron:is_ext_gw". This patch makes use of this key to identify
them in the ``get_lrouter_gw_ports`` method.

This implementation will be useful when the "Logical_Router_Port"
would be bound to an external tunnelled networks. These ports won't
be bound to a "Gateway_Chassis" and the previous logic in this
method will fail.

[1]https://review.opendev.org/c/openstack/neutron/+/907402

Partial-Bug: #2052821
Change-Id: Ieac603b0c7a940693a12170b453eea39dd0eaa47
2024-02-23 22:22:35 +00:00
Rodolfo Alonso Hernandez 981df94416 [OVN] Remove ``create_lrouter`` and ``delete_lrouter`` implementation
The OVN Northbound ``create_lrouter`` and ``delete_lrouter`` local
implementations have their counterparts in ovsdbapp library, in the
methods ``lr_add`` and ``lr_del``.

Trivial-Fix

Change-Id: I57d0847a5f1ed8881c80fcf0ab022d768656ee2f
2024-02-22 09:35:58 +00:00
Zuul df13cbd118 Merge "[OVN] Add ``ProviderResourceAssociation`` to any ML2/OVN router" 2024-02-16 16:00:59 +00:00
Zuul a8fe0cb369 Merge "[OVN] A LRP in an external tunnelled network has no chassis" 2024-02-14 15:59:24 +00:00
Rodolfo Alonso Hernandez d755c2551f [OVN] Add ``ProviderResourceAssociation`` to any ML2/OVN router
Since [1], any Neutron router created with ML2/OVN will have an
associated ``ProviderResourceAssociation`` register. The routers
created before this feature won't have any and it won't be possible
to delete them. This patch adds a temporary maintenance task to
create the needed register for these Neutron routers.

[1]https://review.opendev.org/c/openstack/neutron/+/883988

Closes-Bug: #2053122
Related-Bug: #2020823
Change-Id: Iecd5c7a66b16e25e9888dbd1e305586b2be2011e
2024-02-13 22:28:25 +00:00
Zuul bdc8f87c22 Merge "Log warning about port forwardings that won't work properly" 2024-02-12 13:09:57 +00:00
Zuul 15a4402c89 Merge "Update hacking version" 2024-02-12 13:09:52 +00:00
Rodolfo Alonso Hernandez d55c591ecd [OVN] A LRP in an external tunnelled network has no chassis
A logical router port in an external tunnelled network won't be
scheduled in any chassis. A tunnelled network has no physical
provider network associated thus the logical router port cannot
be bound to a specific chassis.

Related-Bug: #2019217
Change-Id: I140c22899ea3b0240f8c30902fc2dc7055914a18
2024-02-12 08:16:00 +00:00
Zuul 7d2bb8c86f Merge "Not process security group for none active ports" 2024-02-09 19:46:07 +00:00
Slawek Kaplonski a355d2a0d5 Log warning about port forwardings that won't work properly
This is follow up patch to [1] in which was added warning about
incompatible configuration of the vlan/flat networks allowed as tenant
networks, distributed routing and port forwardings.

In this new patch similar warning is logged every time when port
forwarding is created using router which have actually connected vlan or
flat networks as "internal networks" (external gateway network is fine)
and when distributed routing is enabled in the Neutron config.

This patch additionally adds "neutron:is_ext_gw" flag to the
Logical_Router_Port's external_ids. With that it's easier to check if
network is used as gateway network (no checks needed) or not (checks are
perfomed and warning may be logged).

[1] https://review.opendev.org/c/openstack/neutron/+/892542

Related-Bug: #2028846
Change-Id: I101128bdb421ec83df5cdcb0d486cbafbbca2ce5
2024-02-09 16:45:45 +01:00
Brian Haley 542c2ff463 Update hacking version
Update hacking to a more recent version, along with
flake8-import-order.

Remove N347 (import mock library) check as that is the
default with later hacking versions.

Update the builtins override of '_' to be the neutron.i18n
version due to the code triggering a false positive. This
is done in a couple of other projects as well.

Fix a number of new warnings it found.

Added some ignore directives for new whitespace issues
found in the test tree, can fix later.

TrivialFix

Change-Id: I5923255af86cf1fa11ab8e3b03bb9efac7dd7b58
2024-02-08 10:34:10 -05:00
Zuul 737f16715a Merge "[OVN] Add the bridge name and datapath type to the port VIF details" 2024-01-30 11:57:59 +00:00
Rodolfo Alonso Hernandez 70e51eb2ba [OVN] Use elevated context to retrieve subnet in router port configuration
The method ``_get_nets_and_ipv6_ra_confs_for_router_port`` can be called
from a non-admin user request, when updating or creating a local router
port. If the router external gateway network is "external" (as it should
be) but is not explicitly shared (a network RBAC with action
"access_as_shared"), the user won't retrieve the corresponding subnet.

NOTE: is is *not* needed to apply both "access_as_shared" and
"access_as_external" RBACs to a network. Please read c#1 in the LP bug
for more context.

Related-Bug: #2051831
Change-Id: I161f1a6021c0da2d0063f8cb249b3bb9d7b6d5ae
2024-01-29 23:25:44 +00:00
Zuul 2072bb4269 Merge "[ovn] AZs distribution in L3 port scheduler" 2024-01-29 21:23:25 +00:00
Yann Morice a29ea3724e [ovn] AZs distribution in L3 port scheduler
Update l3 ovn schedulers (chance, leastloaded) to ensure that LRP gateways are distributed over chassis in the different eligible AZs.

Previous version already ensure that LRP gateways were scheduled over chassis in eligible AZs. But, depending on the deployment characteristics, all these chassis could be in the same AZ. In some use-cases, it could be needed to have LRP gateways in different AZs to be resilient on failures.

This patch re-order the list of eligible chassis to add a priority on selecting chassis in different AZs.

This should provide a solution for users who need to have their router gateways scheduled on chassis from different AZs.

Closes-Bug: #2030741
Change-Id: I72973abbb8b0f9cc5848fd3b4f6463c38c6595f8
2024-01-26 15:22:34 +01:00
Frode Nordahl 4ccc296f56 [ovn] Honor `enable_default_route_ecmp` attribute
Only create multiple default routes when the router has the
`enable_default_route_ecmp` attribute set to True.

Partial-Bug: #2002687
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Change-Id: I17512ec494661151e46282f0bd08abc55bef1df8
2024-01-26 01:56:33 +00:00
Frode Nordahl 0bc9a71387 [ovn] Implement support for external-gateway-multihoming extension
The general approach is to update the ovn_client and ovn_db_sync
code to handle multiple gateway ports wherever a single gateway
port is handled today.

In this patch set multiple static routes for default gateway will
be added by default when multiple gw ports are present.  Support
for the `enable_default_route_ecmp` attribute to control this
behavior will be added in subsequent patch set to avoid making
this change too large.

Partial-Bug: #2002687
Change-Id: I00b1f29172be5a0034b921b11af3a8d502273766
2024-01-25 20:51:22 -05:00
Brian Haley 3ef02cc2fb Consume code from neutron-lib
All of these exceptions and constants have been in
neutron-lib for a while, start using them.

While looking for other things to consume found an old
neutron-lib TODO that did not apply anymore, so removed.

TrivialFix

Change-Id: I9431075a50ba05be872db422125e6af6266ccb99
2024-01-19 17:18:57 -05:00
Zuul 5ce17647c6 Merge "Router flavors and service type for OVN" 2024-01-17 20:27:17 +00:00
Zuul e6a7cc26a0 Merge "[OVN] Update lsp host id when virtual parent moves" 2024-01-17 18:08:17 +00:00
Miguel Lavalle 49366ecada Router flavors and service type for OVN
Support is added to the OVN L3 service plugin for the router
flavors and service type framework

Partial-Bug: #2020823
Change-Id: If40d7b39e7b59a39ff7622bd823dbdb14bfc69d2
2024-01-17 09:33:07 -06:00
Felix Huettner b5f5f3def3 ovn-l3 scheduler: calculate load of chassis per priority
previously we calculated the "load" of a chassis across the highest
priority of each of the chassis. This can lead to suboptimal results in
the following situation:
* you have gateway chassis: hv1, hv2, hv3
* you have routers:
   * g1: with priority 3 on hv1, priority 2 on hv2, priority 1 on hv3
   * g2: with priority 3 on hv1, priority 2 on hv2, priority 1 on hv3
   * g3: with priority 3 on hv3, priority 2 on hv2, priority 1 on hv1
   * g4: with priority 3 on hv3, priority 2 on hv2, priority 1 on hv1

When now creating a new router the previous algorythm would have placed
prio 3 of it either on hv1 or hv3 since their count of highest
priorities (2 of prio 3) is lower than the count of the higest priority
of hv2 (4 of prio 2). So it might have looked like:
* g5: with priority 3 on hv3, priority 2 on hv1, priority 1 on hv3
(This case has been implemented as `test_least_loaded_chassis_per_priority2`).

However this is actually a undesired result. In OVN the gateway chassis
with the highest priority actually hosts the router and processes all of
its external traffic. This means it is highly important that the highest
priority is well balanced.

To do this now we no longer blindly use the count of routers of the
highest priority per chassis, but we only count the routers of the
priority we are currently searching a chassis for. This ensures that in
the above case we would have picked hv2 for priority 3, since it has not
actually active router running.

The algorithm implemented now is based upon the assumption, that amount
of priorities scheduled per router is equal over all routers. This means
it will perform suboptimally if some phyiscal network is available on 5
gateway chassis, while another one is only available on 2. (It is
however unclear if the previous implementation would have been better
there).

In this commit we also adopt the testcases in test_l3_ovn_scheduler to match
to this assumption. Previously the distribution data used for testing
had been unrelasitic as it mostly scheduled one gateway chassis for each
router.

It also fixes the previously broken priority calculation in the
testcase, that would just assign prio 0 to all gateways.

Partial-Bug: #2023993
Change-Id: If2afcd546a1da9964704bcebbfa39d8348e14fe8
2024-01-17 12:04:09 +01:00
Rodolfo Alonso Hernandez baaf240ce3 [OVN] Add the bridge name and datapath type to the port VIF details
Same as in ML2/OVS, the ML2/OVN mechanism driver adds to the port
VIF details dictionary the OVS bridge the port is connected to
and the integration bridge datapath type.

Closes-Bug: #2045889
Change-Id: Ifda46c42b9506449a58fbaf312cc71c72d9cf2df
2024-01-14 15:51:07 +00:00
Michel Nederlof e68a920c11 [OVN] Update lsp host id when virtual parent moves
When a virtual port is moved from one port to another port the
PortBindingUpdateVirtualPortsEvent event would only update the binding
host id in the neutron database, while it is also usefull to keep the
information in the OVN database up to date with the host information

Other plugins that connect to the OVN database can then also rely on the
information stored in the OVN DB's


Closes-Bug: #2038413

Change-Id: I59c6c4b2c8b023b9c9c3bab1741d957fa1f738fc
2024-01-12 09:50:30 +01:00
LIU Yulong 70eb4006c6 Not process security group for none active ports
We recently met an issue during VM live migration:
1. nova starts live migration
2. plug ports on new host
3. neutron-ovs-agent starts to process the port,
   but the port is in 'added' and 'updated' set
   at the same time.
4. because nova still not activate the destination
   port binding, so there is no local vlan for
   this port.
Then, ovs-agent met errors:
Error while processing VIF ports: OVSFWTagNotFound:
Cannot get tag for port tap092f38ed-a7 from its other_config: {}

This fix is to remove ports of the
"binding_no_activated_devices" for ``setup_port_filters``.

Closes-Bug: #2048979
Change-Id: I0f1e6bf202ef08f75246d6e99b3774d0b6fc9e2b
2024-01-11 15:23:24 +08:00
Zuul dce8c34dd2 Merge "Add a "port" child table "porthardwareoffloadtype"" 2024-01-09 13:21:08 +00:00
Zuul cd28691d3a Merge "[OVN] "description" property missing in ``NeutronAgent``" 2024-01-08 20:57:21 +00:00
Jakub Libosvar 087df97449 [OVN] Remove backwards compatibility with OVN < v20.09 ver 2
This is a followup patch for Iec8854749a1df81eb6a7154d3f951e176c69156d
that left some other unused code in tree. This patch attempts to remove
the remaining pieces.

Related-Bug: 2002839
Change-Id: Ie297dfba17deb79b38cf9f6eccf4f1a8e9e5060a
Signed-off-by: Jakub Libosvar <libosvar@redhat.com>
2023-12-22 05:42:26 +00:00
Rodolfo Alonso Hernandez d603b0fc2c [OVN] "description" property missing in ``NeutronAgent``
The "description" property abstract method definition is missing in
the abstract class ``NeutronAgent``. This property is being used in
this definition, in the "as_dict" method.

Trivial-Fix

Change-Id: I18029707414fc361b36e85326e2e9dadd7d6c336
2023-12-21 22:54:28 +00:00
Zuul ef3089547b Merge "Fix IGMP inconsistency across drivers" 2023-12-18 13:19:07 +00:00
Zuul cf1d5ea35c Merge "[ovn] Add support for IPv6 metadata" 2023-12-15 13:10:13 +00:00