As a result of d92e71c2 the sync util can fail because it tries to
look up the ovsdb connection from the mechanism_manager under 'ovn'
but the sync util registers under 'ovn-sync'.

Change-Id: I6998b08672761a501e427aab5d581064d9425dde
Closes-Bug: #1876752
(cherry picked from Neutron commit 18dd0d4e)

tempest runs in its own venv so it does not need to be pinned to last py2 version

This reverts commit c0772d3a.

Change-Id: I2db34290c07c95cf2c5623886da5c2d9a0f9769f

The QoS OVN client extension is moved to the ML2 driver. This
extension is called from the OVN driver in the events of:
- create port
- update port
- delete port
- update network

The "update_policy" method is called from the OVN QoS driver, when
a QoS policy or its rules are updated.

The QoS OVN client extension updates the QoS OVN registers
exclusively, based on the related events.

NOTE: this patch is an non-straightforward cherry-pick from Neutron
(master branch) patch: https://review.opendev.org/#/c/711317/

Closes-Bug: #1863852

Change-Id: I7b7dca0318dfbe3690b58eccec593e84d08a98aa

When a metadata request arrives to the metadata agent, OVN
will need to figure out which port it corresponds to and it'll do
based on the network ID and IP address which should be a unique pair.

If it's not unique or it doesn't exist, then there is an error
and an ERROR trace is logged.

Change-Id: Id83c2899a03af98e32b0be7ba6ad661e646f07bc
Related-Bug: 1874733
Signed-off-by: Daniel Alvarez <dalvarez@redhat.com>
(cherry picked from Neutron commit 591adfee971906dc86e9357903f164d01657ed65)

The 2.6.0 version introduces some checks that cause failures
with the current code. To avoid that, cap pycodestyle to a
version that had been tested without errors.

Change-Id: I00a35884b14af3e2cf751c04312c847ecfe658c7
(cherry picked from commit 719cae183ae3f67da3ac834140af3f85f2113c10)

The patch removes paunch and cleans network namespaces by iterating over
namespaces belonging to Neutron agents. It also clears side-car
containers spawned by Neutron using podman command.

Change-Id: I017e7b3c3674e065a523eff5ebbea352f619f45e
(cherry-picked from I017e7b3c3674e065a523eff5ebbea352f619f45e)

The networking-ovn has no master anymore, it has been removed at
https://review.opendev.org/#/c/715174/ because the code has now moved
to another repository (openstack/neutron).

Due to this, the release note job will fail and should be removed as
stated in a comment by Andreas at https://review.opendev.org/#/c/704898/



Change-Id: I13c055a8d971dd059ba2ace6f35bcc708b7654af
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>

The ports are unbound from chassis before they get deleted after VM with
normal VIF ports is deleted. In case of SRIOV, we do not unbound the
external SRIOV port but we delete it right away with chassis column set.

This patch adds DELETE event type support to the event that tears down
the metadata datapath. Also a warning is added if bound port that is not
external is being removed.

Change-Id: I17b71933b8c3a7609fcc5027c246f5b03d493ee2
(cherry-picked manually from 76a2f8b33e3f673b96feeb2724ae55567a3b6520)
Closes-Bug: #1875865
Signed-off-by: Jakub Libosvar <libosvar@redhat.com>

Change-Id: Ibfd935e9de15ad3c1c673b550f30096329c034ef

The delete_port() method from OVNClient has a potential problem of
leaving stale ports when RowNotFound is raised from the process to
delete the port from the OVN database. Since the exception is not
granular enough, the RowNotFound could be raised from other objects that
are part of the same transaction (such as ACLs, DNS entries, etc...)
resulting in the revision for the port being deleted even tho the port
is still in the database.

Instead of giving a pass on the RowNotFound exception, this patch is
logging the error and re-raising it without deleting the revision.

(cherry-picked from Neutron I25b93b7c080403fc38365b638e4e03298b447d0f)

Change-Id: Ic0d1234b032a58ce370e1703edc259b584099238
Partial-Bug: #1874733
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>

Prior to this patch, the OVN driver wasn't account for the VNIC types
VNIC_DIRECT_PHYSICAL and VNIC_MACVTAP. These types should work the same
way as the VNIC_DIRECT type in the OVN driver perspective.

(cherry-picked from neutron Idb596b5a80a3155bc9cdee1e082506701e730f00)

Change-Id: Ic3384a75a755e9220dca2aa58e0daa0ac9ebfd7e
Closes-Bug: #1874065
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>

mech_driver.OVNMechanismDriver "_ovn_client" is not a class member but
a read-only property and can't be assigned.

Backported from Neutron (Ussuri): https://review.opendev.org/#/c/715375

Closes-Bug: #1869342

Change-Id: I98f7deaeaad80c840cfccc0dfc3f6f97de05e088

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/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

It is possible to re-use the mech driver ovsdb connections in the
ovn l3 plugin, saving the overhead of two db connections/in-memory
copies of the db per process.

Closes-Bug: #1864548
(cherry picked from Neutron I022dea485f42cf76c4cec67ee43eed9a3770ec9c)

Change-Id: I5fdd80f91ccb23edf6430045d812043e7d3df382

The update_acls code can potentially iterate over the same ACL
twice. This temporary workaround silently ignores an attempt to
delete the same row twice in the same transaction, since that
should be safe. Ultimately, refactoring the ACL code to use sets
and possibly handle the fact that an ACL could be referenced from
multiple rows should be done.

Change-Id: I259c92116f7d3186ae5af45f1407052eb57ac0ba
Related-bug: #1857016
(cherry-picked from Neutron I895eaf4006583fedc2657a4eb527df1ff992c5bc)

If we somehow have an empty set of addresses, lsp_set_addresses
will fail. This instead calls db_clear() on the addresses field if
we are trying to set it to empty.

(cherry-picked from Neutron Ied92eb85b74e63a7317d50970b5131fb49e3e4b0)

Change-Id: If4ca8b6ba75d5d7321cb9ad2c6a9293bd30b796d
Closes-bug: #1860560

With the introduction of OVN 'external' ports, there can be
VIF ports that live in an external chassis. These should be
able to reach the metadata service so if an 'external' port
is bound to a hypervisor, metadata service will be provisioned
for it.

Co-Authored-By: Lucas Alvares Gomes <lucasagomes@gmail.com>
Change-Id: Ib1c1eca68630f08de44aec29b6f6edac5e554f16
Signed-off-by: Daniel Alvarez <dalvarez@redhat.com>
(cherry picked from commit eb696ca7)

This patch is adding support for a new port type called "external" in
core OVN.

Prior to this work, when a VM had a SR-IOV port attached to it, OVN itself
wasn't able to reply to things such as DHCP requests packets since the
OVS port was skipped. Core OVN then introduced the concept of "external"
ports which are ports deployed on a different node than the one that the
VM is running and is able to reply to such requests on behalf of the VM.

With this patch, when a port with the VNIC type "direct" and no
"switchdev" capability is created, ovn driver will then create a
logical port with the type "external" for it and add it to a default
HA Chassis Group. The port will then get bound to the "master" (higher
priority) chassis of that group.

Please note that, as a first step, this patch is creating only one HA
Chassis Group which *all* external ports will belong to. That means that
all external ports will be *scheduled onto the same node* (but it's
HA nevertheless). In the future we should enhance this behavior.

(cherry-pick from neutron Ic6c4bb6c584682169f3ebd73105a847b05dddc76)

This patch also includes a fix for the handle_ha_chassis_group_changes()
method that can be found at https://review.opendev.org/#/c/715445

.

Change-Id: Id8775a0563e33f1878b49a1e797a6912c41caa8f
Closes-Bug: #1841154
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>

Previously the Port Binding event spawned haproxy process even if the
change wasn't done in chassis column, it attempted to spawn haproxy on
all port bindings changes.

This patch spawns haproxy only if new chassis is the one managed by the
agent and old chassis was empty. Similarly it destroys haproxy if new
chassis is empty and old chassis was the one managed by the agent.

Closes-bug: #1868125

Conflicts:
	networking_ovn/agent/metadata/agent.py
	networking_ovn/tests/functional/test_metadata_agent.py

Co-Authored-By: Daniel Alvarez <dalvarez@redhat.com>
Signed-off-by: Jakub Libosvar <libosvar@redhat.com>
Change-Id: I5b87726eafa71d717ae22f48d1c9c6343b680c7f
(cherry picked from commit 06fde66b0b05dc987a4280275813f0cf4bf54c88)