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
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
The "ha" API flag is now enabled for the OVN routers. Because of the
current implementation, this flag must be always "True". When a new
router is created, this flag is always set. If an OVN router is
explicitly created or updated with "--no-ha" (ha=False), the server
will raise an InvalidInput exception.
Depends-On: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/911081
Closes-Bug: #2020823
Change-Id: I60ff33680dd5397a226a9051d51bfb0701f862b5
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
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
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
In case when port_forwarding service plugin is enabled and vlan or flat
network (provider network types) is configured as one of the
tenant_network_types in the ML2 config there is an issue with
centralized and distributed traffic.
FIP port forwarding in ovn backend are implemented as OVN Load balancers
thus are always centralized but if "enable_distributed_floating_ip" is
set to True, FIPs are distributed. And in such case it won't work as
expected as either it tries to send FIP PF's traffic as distributed when
"reside-on-redirect-chassis" for LRP is set to "false" or
tries to centralized everything (even FIP which should be distributed)
when "reside-on-redirect-chassis" is set to "true".
It's not really easy to avoid that issue from the code so this patch
adds warning in the upgrade checks and also log warning about it during
start of the neutron server process to at least warn cloud admin that
such potential issue may happen in the cloud.
Related-Bug: #2028846
Change-Id: I398f3f676c59dc794cf03320fa45efc7b22fc003
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
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
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
Support is added to the OVN L3 service plugin for the router
flavors and service type framework
Partial-Bug: #2020823
Change-Id: If40d7b39e7b59a39ff7622bd823dbdb14bfc69d2
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
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>
Create a constant for the OVN metadata namespace prefix
called OVN_METADATA_PREFIX and use it throughout tree.
TrivialFix
Change-Id: Ib068c49a0cbba3cbf592a337187e3dc70dbae37d
Support for the required DHCPv6 options was recently added in core
OVN with [1].
This patch adds support for that in ML2/OVN backend also and by that
closing one of the gaps between ML2/OVN and ML2/OVS backends.
This patch also adds upgrade check to check used ovn version and warn
operators if native OVN DHCP is used for BM provisioning and OVN version
is older than 23.06.0.
Unfortunately there is no easy way to check used version of OVN so check
relies on the ovnnb schema version.
[1] c5fd51bd15
Closes-Bug: #2030520
Change-Id: Iaa3ff8e97021e44f352e5a9a370714bf5f1d77b8
There are some logic left which checks device owner values set by
LBaaS v1 or v2, but LBaaS was already retired in favor of Octavia.
Change-Id: Ieca7a29a45f0686babe68619ff9da133edd89dec
OVN added support for aging out MAC_Binding entries [1][2].
Without this feature, the MAC_Bindings table can grow indefinitely.
[1] 1a947dd307
[2] cecac71c0e
Closes-Bug: 2033932
Change-Id: I91070ad6addb30ffdedba5d561984d2f6626e2b7
The OVN changed support for NAT rules including a new column and auto discovery logic (which may not work in some cases) [1][2].
If the OVN backend supports this column in the Northbound DB Schema, set gateway port uuid to any floating IP to prevent North/South traffic issues for floating IPs.
This patch updates the method for creating FIP NAT rules in OVN backend and updates previously created FIP rules to include the gateway_port reference. This NAT rule update task runs only once during the maintenance task, and if all entries are already configured no action is performed.
[1] 15348b7b80
[2] 2d942be7db
Closes-Bug: 2035281
Change-Id: I802b6bd8c281cb6dacdee2e9c15285f069d4e04c
This patch introduces a new configuration for OVN CMS Options called
"enable-chassis-as-extport-host". This configuration can be used
by ML2/OVN to identify nodes that are eligible for scheduling OVN's
external ports.
Prior to this patch, external ports were always scheduled on centralized
networked nodes tagged with the "enable-chassis-as-gw" flag in the OVN
CMS Options but, when it comes to deploying OpenStack on OpenShift
requiring services such as the OVN Metadata Agent or DHCP Agent to
serve those external ports and running them on control plane nodes are
not ideal. This is where this patch comes handy allowing these ports to
have more flexibility in where they are scheduled.
The patch is also backward compatible and if the new configuration is
not present on the OVN CMS Options, ML2/OVN will continue to schedule
the external ports on nodes configured with the previous configuration
like always.
Documentation will be updated on a follow up patch.
Closes-Bug: 2037294
Change-Id: Ic46d847e3aebfe543d5a7ab49d18d1f1abf1342e
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
The OVN client code in _get_port_options() was changed in
the following ways:
1) variable ip_subnets was changed to port_fixed_ips to
reflect what it actually was.
2) Instead of just passing the list of subnet dictionaries
to callers and having them iterate it, create a
"subnets by id" dictionary that can be used in multiple
places, including the OVN utilities.
3) Move the calls of get_subnets_address_scopes() and
get_port_type_virtual_and_parents() so they are only
made if there are subnets associated with the port.
The OVN utility code was changed to accept the "subnets by id"
dictionary mentioned in #2.
Functionally the code should be identical.
Required a lot of test cleanup.
Change-Id: I3dd4c283485c316df0662b5d679b6e13f65b4841
In [1] we added support for FDB learning. In order to avoid issues
due to that table increasing without limits, which will impact OVN
performance, this patch is adding support for its aging mechanisms
which was added in OVN 23.09 in [2]. By default is disabled, so if
`localnet_learn_fdb` is enabled, the new configuration parameters
should be appropriately configured too: `fdb_age_threshold` and
`fdb_removal_limit`
[1] https://review.opendev.org/c/openstack/neutron/+/877675
[2] ae9a548882
Closes-Bug: 2035325
Change-Id: Ifdfaec35cc6b52040487a2b5ee08aba9282fc68b
OVN metadata and OVN LB HM port (used for health checks) are both
using network:distributed in the device_owner field. Some tasks
in Neutron search by that value, considering just one port will
exist per network with that value.
This patch adds a new constant to differentiate OVN metadata ports
from the OVN LB HM ones. The latter will use a device_owner
of ovn-lb-hm:distributed to be different but will still receive the
treatment of a localport in the OVN NB DB.
Related-Bug: 2038091
Change-Id: I70de163fad34371de10fec28c51959384900ebc8
The Neutron "port.status" field ("ACTIVE", "DOWN") is set depending on
the Logical Switch Port "up" and "enabled" flags. Before this patch,
the "port.status" depended only on the "up" flag. However, the user
can set the "port.admin_state_up" field that will modify the
"lsp.enabled" flag. If the "port.admin_state_up" is DOWN, the port
does not transmit and the status should be "DOWN".
The OVN backend is correctly disabling the port transmission; what
was incorrect in the Neutron API is only the "port.status" field.
This is currently working in other mechanism drivers like LB or OVS.
Closes-Bug: #2036705
Change-Id: I5b7b55b0b365df7246a571cea97a392cdf89bdb6
Since the additional_chassis column [1] is used during the live
migration in order to optimize the VM network timeout, we can also use
this to minimize downtime for the metadata service. The patch adds
additional match to when new Port Binding is introduced to the chassis
associated with a node. This triggers the provisioning of metadata
resources a lot earlier in the process, while the VM is still in paused
state.
[1]
35fade3b5f
Closes-bug: #2036118
Change-Id: I66fa3c541db54c5f57404681f30b141fe8dad84a
Signed-off-by: Jakub Libosvar <libosvar@redhat.com>
In most typical use cases ML2/OVN backend don't needs to run DHCP agent
as OVN provides DHCP functionality natively. But there are some use
cases like Baremetal provisioning over IPv6 or Spine Leaf architecture
with DHCP relays where DHCP agent is necessary and it can work perfectly
fine with ML2/OVN backend.
The problem was that dhcpagentscheduler API extension wasn't listed as
supported by the OVN backend so it was filtered out from the list of
supported extensions during start of the neutron server. This caused
problems with API to get/set/delete networks to/from DHCP agent.
This patch adds this API extension to the list of the extensions
supported by the OVN driver to fix that issue.
Depends-On: https://review.opendev.org/c/openstack/tempest/+/898090
Closes-bug: #2038655
Change-Id: I09a37ca451d44607b7dde344c93ace060c7bda01
This new extension adds a new synthetic field, "belongs_to_default_sg",
to the security group rule OVO. This read only boolean field determines
if the security group rule belongs to a default security group or not.
This new field will be used in a new set of policy rules. By default,
these new rules will allow to create and delete security group rules
into the default security group of a project only to the admin user
NOTE: the follow-up patch will introduce the policy rules check,
during the creation/deletion operations, of the
"belongs_to_default_sg" field and the user executing this action.
Partial-Bug: #2019960
Change-Id: I0b3ded52e1ff8160c5804c59635c0fd34ce9995b
Since [1], present in oslo.log 5.3.0, the ``log.setup`` method is
unpatching the evenlet thread module. That is causing several problems
in some Neutron services, in particular the keepalived-state-change
service.
Within this oslo.log version, the patch [2] is provided to call this
method without unpatching any eventlet module.
This patch is also bumping the minimum required version of oslo.log
to 5.3.0, in order to call the ``log.setup`` method with the kwarg
"fix_eventlet=False".
[1]https://review.opendev.org/c/openstack/oslo.log/+/852443
[2]I4bbcfe7db6d75188e61b9084cb02b2dd2aaa0c76
Closes-Bug: #2037239
Change-Id: Iea77d20bec330b692e3e8c9e38b3a62e2047b4f4
If a port receives a device ID and a binding profile host ID
fields update, at the same time, this is because Nova is trying
to bind the port to a VM (device ID) in a host (host ID). In
ML2/OVN, a virtual port cannot be bound to a VM.
NOTE:
* A virtual port can receive a host ID update. That happens when
the fixed IP port that has the virtual port IP address as
allowed address pair is bound.
* A virtual port can receive a devide ID update. Octavia uses
the devide ID to identify to what load balancer the virtual
port belongs.
This check was introduced in [1].
[1]https://review.opendev.org/c/openstack/neutron/+/882588
Closes-Bug: #2028651
Related-Bug: #2018529
Change-Id: I8784c6716f5a53b91d43323771e6f30fa8e8e506
This patch implements the new network HA boolean field API extension.
This field is an input only parameter for POST operations (creation).
By default is "False". When enabled, the Neutron server will create
a ``ha_router_networks`` register in the same transaction of the
network creation.
If by any circumstance (a race condition, for example), another
``ha_router_networks`` exists in the same project, a
``DBDuplicateEntry`` exception will be raised and the transaction
will be rolled back.
Partial-Bug: #2016198
Change-Id: Ie42c13ecbe4abcad9229b71f6942e393fd0f2e4e
Skip the port status UP update during a live migration due to a
``PortBindingChassisUpdateEvent`` event.
The port status will be set by the ``LogicalSwitchPortCreateUpEvent``
and ``LogicalSwitchPortCreateDownEvent`` events, that will be issued
when the port is deleted from the source host and created in the
destination host. This is a planned operation and controlled by Nova,
not a reactive event due to an unplanned host down event.
Related-Bug: #2027605
Change-Id: I81390af2ea2fc384423518b84de3acf7adaf9193