Right now, as per kernel limitation, the burst limit is not correctly
enforcing the rate and burst when using the ovn "log-related" option and
stateless security groups. We log exactly double the burst. Creating a
new meter that limits the rate and burst to half of the expected ones is
a workaround that solves the issue.
Closes-bug: #2032929
Signed-off-by: Elvira García <egarciar@redhat.com>
Change-Id: Ib0047d38c58bcebb23c8887e7934987ff8c8a432
This patch introduces a maintenance task that runs once a day and is
responsible for cleaning up Hash Ring nodes that haven't been updated in
5 days or more.
Change-Id: Ibed9e0d77500570c3d0f9f39bfe40cb9239d0d7a
Closes-Bug: #2033281
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
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
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
The mcast_flood_reports option was being enabled on LSPs as a workaround
for a problem in core OVN. The issue in core OVN has been fixed and this
workaround is now causing an increase in the number of actions on the
table 38 of OVN (at the risk of hitting a size limit).
This patch disables the mcast_flood_reports option on newer versions of
OVN while keeping the backward compatibility with the old ones.
Since the fix in core OVN does not expose any information to the CMS to
tell us that the issue is fixed this patch uses the NB DB schema version
to determine if this is an old or a new OVN version.
Change-Id: I8f3f0c2d516e37145eb298b8f51d92fe9905158a
Closes-Bug: #2026825
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
There's a sync issue while trying to fetch the hosting information for
the LSP before we write it to the OVN database, sometimes the
information is not yet present and we end up with an empty string ("")
for the host attribute of portbindings. This patch adds a retry
mechanism to solve this sync issue.
Change-Id: I52ec4b346271889ebaa7b7f84981eae5503d02d3
Related-Bug: #2020058
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
Prior to this patch the ovn-db-sync script did not check if the router
ports were actually out-of-sync before marking them to be updated. This
behavior introduced irrelevant information in the sync report (specially
when ran in "log" mode) making the user think that the databases were
out-of-sync even when they were not.
This patch adds the code checking for differences in the Neutron Router
Ports and OVN Logical Router Port entries prior to updating them.
Change-Id: Id7bf5a6aa547795ba78724eed59ba9d4fb74f758
Closes-Bug: #2030773
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
There are a few different places that check if a port
is for OVN metadata. Create a common method in
neutron.common.ovn.utils so the same check is done in
all cases and change all current code to use it.
Trivialfix
Change-Id: Id61a6af5f3c55d6caef273b70263ae3a6760c912
After updating pylint, it started emitting additional "W"
warnings in some cases, fix some of them.
modified-iterating-list,
implicit-str-concat,
global-variable-not-assigned
Trivialfix
Change-Id: I7deb5f1e0aa2852cb033c78dcb4c8bc87e34be1e
This patch implements a more resilient approach to handle the case
where Neutron API workers are killed and restarted. Instead of marking
all nodes for that host as offline, this patch tries to remove the
worker that was killed from the Hash Ring leaving all others nodes for
that host online.
In case the we fail to remove the node and another entry is added upon the
restart of the worker this patch also logs a clear critical log message to
alert the operator that there are more Hash Ring nodes than API workers
(it's expect to be the same) and that OVSDB events could go missing if
they are routed to the previous node that failed to be removed from the
ring.
Closes-Bug: #2024205
Change-Id: I4b7376cf7df45fcc6e487970b068d06b4e74e319
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
After updating pylint, it started emitting additional "R"
warnings in some cases, fix some of them.
use-a-generator,
unnecessary-lambda-assignment,
consider-using-max-builtin,
consider-using-generator,
consider-using-in,
use-list-literal,
consider-using-from-import
Trivialfix
Change-Id: Ife6565cefcc30b4e8a0df9121c9454cf744225df
The maintenance worker from the neutron-api uses a southbound
connection. Since the southbound does not use any locking and all the
ovsdb locking is used for the northbound this changes should not have a
big impact.
This commit removes the leader_only flag for the maintenance worker.
This should also enable the neutron api to connect to relays instead of only
the sb directly.
Closes-Bug: #2022914
Change-Id: Ia7937390867e45af34ebcd65bd76fc89b6adafe9
Signed-off-by: maximkorezkij <maxim.korezkij@mail.schwarz>
A TypeError was thrown during a synchronization
command(neutron-ovn-db-sync-util) execution. From the code[1][2], it
can be seen. The result of the AddLSwitchPortCommand command will be
passed as a parameter to the UpdateLSwitchPortQosOptionsCommand. But
if the logical switch port exists, the result will not be set. Therefore,
when the UpdateLSwitchPortQosOptionsCommand is executed, the port_id
will not be obtained, thereby throwing an exception TypeError.
This patch sets the result when the logical switch port exists.
[1] b71f7ceb3e/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py (L488)
[2] b71f7ceb3e/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_client.py (L505)
Closes-Bug: #2025202
Change-Id: Ie09d9d3e5efa8a57ad11655c2eb31d2604bab326
A LSP is type=virtual when its IP address is used by other ports
as allowed address. If a LSP is type=virtual, this port cannot be
bound (that means cannot be used as a port for a virtual machine).
Closes-Bug: #2018529
Change-Id: I1943e6e0d7d8e255e95f93881cc3caec16ab67fe
Expose chassis hosting information via LSP's external_ids. This allows
for projects such as ovn-bgp-agent NB driver that only connects to the
NB database to consume such information (avoiding more connections to
the SB database).
Also stop populating the "requested-chassis" options for ports of the
type virtual because it's ignored by OVN.
See LP #2020058 for more information.
Closes-Bug: #2020058
Change-Id: I1fb6a9ff94376ab5f695d311b6fa8034d73cf556
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
There is no need to clear the external_mac if DVR is enabled, not
even when the port is down. This patch ensures the external_mac is
only deleted when DVR is not enabled.
Without this patch, if a VM with a floating IP gets deleted, and
DVR is enabled, during some time the traffic gets (wrongly)
centralized while it should not. And it is also generating more
load on the OVN side unnecesarily.
Closes-Bug: #2025264
Change-Id: I89db15dd1b629bc963f3b63926391a4a02cbedf7
If the floating IP updates only the QoS policy, the method now
skips the OVN NAT rules update and updates only the QoS policy.
That avoids the OVN NAT rules deletion and creation and the
``FIPAddDeleteEvent`` event that deletes the MAC binding entries
for an active floating IP, causing a disruption.
Closes-Bug: #2025144
Change-Id: Ib9ec45d643c6162c526cd5a02db270094b575e34
After updating pylint, it started emitting additional "E"
warnings in some cases, fix them.
unsubscriptable-object,
unsupported-delete-operation
These were associated with the OVN AgentCache code. Instead
of using a subscript, create get/delete methods to do the
same thing.
used-before-assignment
Re-factor some code so it's clear to pylint variables are
being assigned properly.
Trivialfix
Change-Id: I4a5ccb7f33465705e59b5274c41db3c371862b1e
A new OVN maintenance method is added. This method lists all existing
OVN SB Chassis registers and checks if any of them has the same
hostname. In case of having duplicated "Chassis"/"Chassis_Private"
registers, the maintenance method will remove those with older
(lower) timestamp, that is stored in
"Chassis_Private.nb_cfg_timestamp", leaving only the newer one.
Closes-Bug: #2016158
Change-Id: Ib3c6f0dc01efd31430691e720ba23ccb4ede65fa
This patch implements the proposed solution from LP #2024205 where upon
a Neutron being killed, it could trigger the deletion of the entries
from the ovn_hash_ring table that matches the server hostname. When
this happens on all controllers this could lead to the ovn_hash_ring
being rendered empty which will result in ML2/OVN not processing any
OVSDB events.
Instead of removing the nodes from the ovn_hash_ring table at exit, this
patch changes the code to just mark them as offline instead. That way,
the nodes will remain registered in the table and the heartbeat thread
will set them as online again on the next beat. If the service is
stopped properly there won't be any heartbeat anymore and the nodes will
be seeing as offline by the Hash Ring Manager (same as if they were
deleted).
For more info see LP #2024205.
Closes-Bug: #2024205
Change-Id: I052841c87651773c4988fcf39f9f978094297704
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
This reverts commit be4e150de9.
Reason for revert: some CI gates (devstack for example) are still
using some OS (Ubuntu Focal) that provide older OVN version. On
these jobs we are not manually compiling OVN.
Change-Id: Ia716f73dffa94c9fecbcc1a7dd0f10cb62639671
Rodolfo Alonso Hernandez