The method "sync_ha_chassis_group" now creates (or retrieves) a
HA Chassis Group register and updates the needed HA Chassis registers
in a single transaction. That is possible using the new ovsdbapp
release 2.2.1 (check the depends-on patch).
Depends-On: https://review.opendev.org/c/openstack/ovsdbapp/+/871836
Related-Bug: #1995078
Change-Id: I936855214c635de0e89d5d13a86562f5b282633c
This reverts commit 6358495720.
Reason for revert: This is generating a lot of
"SecurityGroupNotFound" errors in neutron-server.log in
the tempest-integrated-networking job.
Closes-Bug: #2019449
Related-Bug: #2008712
Change-Id: I077fe87435f61bd29d5c1efc979c2adebca26181
In some corner cases, like when db_sync is performed after OVS to OVN
migration, an implicit metadata port creation on a network with
depleted IP pool can raise IP allocation error. Just catch and log
this error such that the db_sync tool can finish syncing.
Change-Id: Ibb32ec5492c4fe00b9dac510f7e69160982992dd
The method `OVNClient._add_router_ext_gw`` must use the API context
passed instead of creating an admin one.
Closes-Bug: #2019132
Change-Id: If2a46f1e0c3b279dee4863e9c952f19c1e246571
Up until now, we needed to remove all logging objects to see the
meter-band properties being changed after a server restart. Now we check
for inconsistencies between the neutron configuration and the OVN
meter-band object after a restart. The function create_ovn_fair_meter is
now located in the ovn_driver instead of the log_driver so as to be able
to call it from the maintenance task.
Closes-bug: #2017145
Signed-off-by: Elvira García <egarciar@redhat.com>
Change-Id: I24cef85ed68c893a740445707f88296d763c8de8
This patch removes the compatibility with OVN under v20.09. That
implies the OVN Southbound definition has "Chassis_Private" table.
Any previous check is removed from the code.
This patch also adds a sanity check, testing that the OVN Southbound
database definition is greater or equal to 2.9.0 [1].
The testing OVN NB and SB schemas are updated to the files contained in
OVN v22.09. The new testing NB schema version is 6.3.9; the new testing
SB schema version is 20.25.0.
[1]4adc10f581
Closes-Bug: #2002839
Change-Id: If64c967b89099946165bfaf66247def4881af832
When a subnet is updated, for example, to disable then
re-enable DHCP on it, if there is no metadata port it
will just return without trying to allocate an IP,
leaving DHCP unusable on the subnet. This could happen
if an admin, even accidentally, deletes the DHCP port
on a subnet while DHCP is disabled.
This also makes OVN behave like ML2/OVS, which will
re-create the DHCP port when the enable_dhcp flag is
changed to false and back to true.
Change-Id: I943f2fb4db9dc33dc372f844d6133faff415befe
Closes-bug: #2015377
The `get_gw_port` parameter is currently unused, the
implementation hiding behind it also contains a bug, remove it.
Partial-Bug: #2002687
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Change-Id: Ie0ba5a478fabe9880746f892ef9c00d7e5660195
An update to the OVN QoS driver to support the `qos_gateway_ip`
QoS extension [0] introduced adding the GW network id as an
external_id on the Logical_Router (LR). This is problematic
when introducing multiple gateway ports, because a single LR
can have gateways in multiple networks.
The external_id key was presumably added because at the point in
time when a LR is deleted, the code had no other source of this
information. However, it turns out this step is redundant and
not neccessary.
To prove this I include a excerpt of a stack trace when deleting
a router in the commit message:
File "services/ovn_l3/plugin.py", line 210, in delete_router
super(OVNL3RouterPlugin, self).delete_router(context, id)
File "db/l3_db.py", line 612, in delete_router
self._delete_current_gw_port(context, id, router, None)
File "db/l3_db.py", line 452, in _delete_current_gw_port
self._core_plugin.delete_port(
File "plugins/ml2/drivers/ovn/mech_driver/mech_driver.py",
line 886, in delete_port_postcommit
self._ovn_client.delete_port(context.plugin_context, port['id'],
File "plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py",
line 830, in delete_port
self._delete_port(port_id, port_object=port_object)
Essentially, a routers GW port(s) will be removed prior to
deleting the router itself.
The `ovn_client.delete_port` method will call on the QoS extension
to remove rules matching the GW port, and that will be the same
rules as has previously been added for the router.
I also added a functional test that confirms this fact [1].
0: I46864b9234af64f190f6b6daebfd94d2e3bd0c17
1: Ic92a7b3bd73920d08dee41974bfe3aeb1c64b557
Partial-Bug: #2002687
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Needed-By: I95a0d5f1b7aef985df5625cd83222799db811f2b
Change-Id: If7c22bc8a95fa13e746c86a1e9d4a6fa25496e1f
At present Neutron maintains an external_id on the
Logical_Router (LR) representing the gw port (singluar). This
is problematic when introducing multiple gateway ports.
Instead we can find Logical Router Port (LRP) that act as
gateways for the LR at runtime by looking for configuration
present on all GW ports.
Partial-Bug: #2002687
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Needed-By: I95a0d5f1b7aef985df5625cd83222799db811f2b
Change-Id: I8a915dca1410c70bdfe7a2d72931921d2a1a265e
In OVN 22.09, the option "localnet_learn_fdb" was added so that
localnet ports can learn MAC addresses and store them in the FDB
table. This avoids flooding issues for VMs on provider networks
when port security is disabled
Closes-Bug: #2012069
Change-Id: I93574b4fe9a79b649bfe755cf7e0697ccc7eb83a
As part of [1] the redirect-type=bridged flag was enabled by default.
However this have the side effect of also decentralizing N/S traffic
for geneve tenant networks, breaking the VM connectivity on them when
it must be centralized, i.e., when no FIPs are associated to the VMs.
This patch differentiates and only enable that flag when the networks
conected through that router gateway port are of VLAN/FLAT type.
In addition, to avoid MTU issues for the VLAN networks if there are
also geneve networks connected to the same router, we re-take the
approach on [2] to ensure the traffic is centralized but not tunneled
[1] https://review.opendev.org/c/openstack/neutron/+/875644
[2] https://review.opendev.org/c/openstack/neutron/+/875676
Closes-Bug: #2012712
Change-Id: I25e5ee2cf8daee52221a640faa7ac09679742707
This reverts commit 8e3bddbf8b.
Reason for revert:
As part of the reverted commit, the redirect-type=bridged flag was
enabled by default. However this have the side effect of also
decentralizing N/S traffic for geneve tenant networks, breaking the
VM connectivity on them when it must be centralized, i.e., when no
FIPs are associated to the VMs.
A new fix will be provided ASAP.
Change-Id: I30b1328b30f1b36b8b7ee556aa52ac6b2dd91d4e
Based on bug #2008712 if we have a security-group which
is the remote group of a 2nd security-group, the backend
never deletes the rule of the 2nd group which
remote_group_id is the original security-group.
By AFTER_DELETE event for each rule that has the
security_group_id as remote_group_id, we can make the
mech drivers do their work and delete these rules in the
backend.
Change-Id: I207ecf7954b06507e03cb16b502ceb6e2807e0e7
Closes-Bug: #2008712
The metadata port fixed IPs depend on the subnets "enabled_dhcp" flag.
If the subnet has this flag disabled, the metadata port doesn't receive
an IP on the subnet CIDR.
The method ``create_metadata_port`` should explicitly define what fixed
IPs should request the metadata port during the creating depending on
the subnets "enabled_dhcp" flag.
Closes-Bug: #2011724
Change-Id: If362fab20ac03f8b62471b60c031f9349171ce93
It is very wasteful to create a frozen row copy for every event
that we process. It can dramatically increase the time to process
the initial events from connecting to the database.
Closes-bug: #2011590
Change-Id: Ic4bf26d9b1f937073ddc6d0c3e9d22a777912ebf
The function is supposed to omit neutron_pg_drop Port_Group (as per its
docstring) but it actually returns it because of incorrect if-statement
structure.
The function is not used anywhere in the tree and hence doesn't affect
any feature, at least in master.
(It was used before I27af495f96a3ea88dd31345dbfb55f1be8faabd6.)
The function will be used in a consequent patch, so it now becomes
important to make it behave as documented.
Related-Bug: #2009053
Change-Id: I0c5d3db521131cc71135a9c787ed01479b451cfb
This patch partly reverts the workaround introduced at [1].
In patch [1] the reside-on-redirect-chassis was forced for vlan provider
networks to force centralized but not tunneled traffic for those
network. In this patch we are making use of the "redirect-type" flag
instead so that the traffic can be distributed and still not tunneled.
This flag needs to be set on the router gateway port (port connecting
the router to the external network) unlike the previous one that was set
on the router interface port (port connecting the (vlan) internal
network to the router). In this patch we are setting it on all ovn
gateway ports if DVR is enabled, as:
- It is needed for vlan (provider) network to have their traffic
distributed instead of tunneled to the controller where the cr-lrp is
associated
- It is not having any effect on the geneve tenant networks as it only
applies to network that has a localnet port associated to them.
[1] https://review.opendev.org/c/openstack/neutron/+/871252
Closes-Bug: #2003455
Change-Id: Ia05416df88904e864d4fc9760ffcdc97a4651f9f
This patch adds an extra checking to ensure the
"reside-on-redirect-chassis" is set to true for the logical
router port associated to vlan provider network despite having
the "ovn_distributed_floating_ip" enabled or not. This is needed
as there is an OVN bug [1] making it not work as expected.
Note setting this to true has implications as the traffic will be
centrallized (but not tunneled) through the node with the gateway
port.
The expected behavior of this flag, once [1] is fixed is:
- reside-on-redirect-chassis flag to False: means traffic goes
tunneled to the controller with the gateway port. Means it requires
extra MTU reduction to work.
- reside-on-redirect-chassis flag to True: means traffic is not
tunneled to the controller with the gateway port, but the traffic is
centralized through the controller with the gateway port. Thus it
does not require extra MTU reduction.
- reside-on-redirect-chassis to False, but with ovn-chassis-mac-mappings
configured: means the traffic is fully distributed and it is not being
tunneled, nor sent, through the controller with the gateway port. This
is the preferred option as it does not require MTU reduction and it
avoids the extra hop. However it is not working as expected, therefore
the fallback to set reside-on-redirect-chassis to True.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2162756
Closes-Bug: #2003455
Change-Id: I662cb30c842e54bb9f7dabac5519283aa7c7f8d0
A recent change [1] to show the real heartbeat timestamp from OVN agents
had a side effect of changing the timestamp format, which now includes a
timezone:
+-------------------+----------------------------------+
| Field | Value |
+-------------------+----------------------------------+
| last_heartbeat_at | 2023-02-23 14:12:07.471000+00:00 |
+-------------------+----------------------------------+
This unexpected format change causes some clients to fail to parse the
response to GET /v2.0/agents.
Normalise the format of the timestamp to remove timezone information.
Also remove the microsecond part, which was not done for OVN, but is
absent from other network agents.
[1] https://review.opendev.org/c/openstack/neutron/+/844179
Closes-Bug: #2008257
Change-Id: I75a37fb9b49a421e4524da6b56ef8362ceb6107b
The ``OVNTrunkHandler`` class updates the port binding profile of the
trunk subports. The methods ``_set_binding_profile`` and
``_unset_binding_profile`` update both the OVN LSP register and the
Neutron DB port register. This patch adds the missing field
"neutron:device_owner" from the LSP external_ids dictionary.
This patch also updates ``OvsdbNbOvnIdl.set_lswitch_port`` API method.
The method now accepts "external_ids_update" kwarg. This dictionary
allows to update (or add) individually each LSP.external_ids
dictionary key, instead of overwritting the whole variable.
NOTE: ``set_lswitch_port`` is not used outside Neutron now so this is
safe to change the API method signature.
Closes-Bug: #2006735
Change-Id: I985f3294b2ca7ab5989022ec1b904c8e29354e07
In the method ``add_vnic_type_and_pb_capabilities_to_lsp``, if the port
binding profile is an empty string (or something that cannot be parsed
by jsonutils), skip this port.
Closes-Bug: #2006112
Change-Id: Ifa8956bf1c5eb9b6c3214638ac4e5b7f10e4cf74
While other SQL engines can compare interger and boolean types,
PostgreSQL needs explicit casting to compare variables. Method
"_sync_subnet_dhcp_options" is currently raising the following
error:
operator does not exist: boolean = integer
Closes-Bug: #2004581
Change-Id: I715029c311c4516f3212054c5c72533b12fd0986
The virtio-forwarder related code has already been written in other
neutron components except OVN. Added logic solving virtio-forwarder
in OVN plugin.Add unit tests of virtio-forwarder VNIC type. Test
cases include test_create_port_with_vnic_virtio_forwarder,
test_bind_virtio_forwarder_port_geneve,
test_bind_virtio_forwarder_port_vxlan.
Closes-Bug: #1988542
Change-Id: I80f32db761f5813409c6f789177b2fdebf643305
This patch adds config option to let cloud operator to disable
'stateful-security-group' API extension if OVN < 21.06 is used. This is
the case e.g. on Ubuntu 20.04 where OVN 20.03 is provided.
In case when API extension is enabled and OVN < 21.06 is used, Neutron
will fallback to stateful ACLs even for stateless security groups which
may be confusing for Neutron API users.
This needs to be done with config option and not by checking
automatically in OVN if "allow-stateless" is supported keyword for ACL's
action because it needs to be done during initialization of plugin,
where IDL isn't initialized yet and it would cause deadlock when Neutron
would try to connect to the OVN NB.
Closes-Bug: #2003999
Change-Id: I62e77dad2782e9c546745e860fda7622a8281739
notify() is called from python-ovs code which is not built to
recover from an exception in this user-overriden code. If there
is an exception (e.g. the DB server is down when we process
the hash ring), this exception can cause an unrecoverable error
in processing OVSDB messages, rendering the neutron worker useless.
Change-Id: I5f703d82175d71a222c76df37a82b5ccad890d14
This patch introduces the new OVN Neutron Agent definition in the
OVN agent list and creates a new class ``OVNNeutronAgent``.
Related-Bug: #1998608
Change-Id: I57de801473fc30f06acf1bc8a65cb2ff76b2954a
In order to decide if a port is a hardware offloaded port by just
reading the OVN Logical_Switch_Port register, it is needed the
VNIC type and the binding profile cababilities.
The maintenance task will only update those LSP ports that belong
to direct Neutron ports to avoid an unnecessary database load.
Related-Bug: #1998608
Change-Id: I5febe9d3eeef6c5b5f6d972b9e8ebfef541458ac
Before this patch, if a OVN router was associated with an
external network whose subnet had an empty `gateway_ip`, a
default route with an empty dst-ip is created in the OVN
database.
As documented in the Neutron API [0], it is allowed to create
a subnet without a gateway_ip.
0: https://docs.openstack.org/api-ref/network/v2/index.html?expanded=create-subnet-detail#create-subnet
Closes-Bug: #2002993
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Change-Id: Ica76e0821d753af883444d2a449283e9e69ba03f
Zuul