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
(cherry picked from commit d55c591ecde2f6cc4c2cea64fb21a75b6343cd5a)
This patch adds info about the fact that FIP PFs aren't working when
in the ML2/OVN backend distributed routing is enabled and provider
networks are added to the router as internal networks.
Conflicts:
doc/source/ovn/gaps.rst
Related-Bug: #2028846
Change-Id: I3a0ab43c52a3090257a1accaee00f33abff54e74
(cherry picked from commit cce872ead3026d72f946ec8687589715d647a1b4)
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
Conflicts:
neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/maintenance.py
neutron/tests/unit/services/ovn_l3/test_plugin.py
Related-Bug: #2028846
Change-Id: I101128bdb421ec83df5cdcb0d486cbafbbca2ce5
(cherry picked from commit a355d2a0d55b62e4337d5c71dc4c4049883c59c3)
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.
Conflicts:
neutron/cmd/upgrade_checks/checks.py
neutron/common/ovn/utils.py
neutron/tests/unit/cmd/upgrade_checks/test_checks.py
Related-Bug: #2028846
Change-Id: I398f3f676c59dc794cf03320fa45efc7b22fc003
(cherry picked from commit ce53fb55ade372431af634638ff90d41ffa88ea3)
Since [1], we introduced a way to skip the load of the OVO synthetic
fields depending on the resource fields retrieved. In the case of the
security groups (SG), the SG rules are child objects to the SGs. The SG
rules are retrieved when a SG OVO is created.
The improvement done in [1] is to make the SG rules load dynamically,
that means using the load mode "lazy='dynamic'". That will issue a SQL
query only if the SG rules are read; if not, the query is never issued.
However since [2] (and this is previous to the [1] optimization), we
always add the field "shared" to the filters and thus to the fields to
retrieve, because it is a policy required field. Because "shared" is a
synthetic field [3], that will force the SG "synthetic_fields" load and
the retrieval of the SG rules always. This is undoing any performance
improvement.
This patch is changing the loading method to "joined"; that will request
the SG rules in the same SQL query, instead of issuing separate queries
for the SG rules. Until a method to load the SG "shared" field,
independently of the synthetic OVO fields is implemented, this change
will improve the SG retrieval performance. In a testing environment
with around 5500K SG and 4 rules (default ones) per SG:
* lazy='dynamic': 38 seconds
* lazy='select': 20 seconds
* lazy='joined': 12 seconds
[1]https://review.opendev.org/q/topic:%22bug/1810563%22
[2]https://review.opendev.org/c/openstack/neutron/+/328313
[3]b85b19e384/neutron/objects/rbac_db.py (L349)
Related-Bug: #2052419
Change-Id: I300464472f2348d148f2a3ddac384c883d9d815b
(cherry picked from commit 52662cad7a07f9bb3b954366eeccd9795ae21503)
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
(cherry picked from commit 70e51eb2baac3c891d735aa5ffbeb4fca425f29b)
Usage of the helper function which retrieves the name of the process
based on the usage of the segments was missing for unregister which
leads an issue when disabling dhcp agent for a network.
Closes-Bug: #2051690
Signed-off-by: Sahid Orentino Ferdjaoui <sahid.ferdjaoui@industrialdiscipline.com>
Change-Id: Ic6e999214210383f17c29982bf5673eea1bb55c0
(cherry picked from commit b37c0f45c833a3ff1589b5932a8300ffd6017be3)
The shell command "ovsdb-client", in the functional tests, is prone to
timeouts. This patch adds a tenacity decorator and sets the command
timeout to 3 seconds, that should be more than enough to retrieve one
single register.
Closes-Bug: #1955008
Change-Id: I38626835ca809cc3f2894e5f81fab55cf3f40071
(cherry picked from commit 64fddf4f2d18b134b5cc8348049a3c4f10f69a28)
There were 3 tests which were testing update of the segmentation_id for
the network with:
* no ports
* unbound or binding failed ports,
* bound ports.
Due to the nature of the fullstack tests, each of tests required to
spawn neutron server, neutron ovs agent, etc.
Now all of those tests are consolidated into one test end execution time
of test cases from that class went down from about 125 seconds to around
45 seconds.
Change-Id: I4c0444700bff734cf1947f0e0a3e44ea0e11a155
(cherry picked from commit 8935b7a133de5dc8e6d92834e74bc3be89fb96af)
This fullstack test is now replaced by the API test in
neutron_tempest_plugin (see depends on patch).
Depends-On: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/902753
Change-Id: I2d01b6bf65ebb4dd5bf50e3aca2b3c69a2b70d23
(cherry picked from commit ef15700055467e8459b7309a168aeb4eb392acea)
This fullstack module contains only one test test_port_shut_down and it
is now replaced by the API test in neutron_tempest_plugin (see depends
on patch).
Depends-On: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/902638
Change-Id: I79bdc4a48ddbdb7d5872ec9422e97445bf7fa553
(cherry picked from commit fea0e7d0aef6406826d97da494c2ad9a09bf920f)
This patch removes some of the fullstack test cases which aren't really
needed because they are either testing some use cases covered already by
scenario tests or some other common tests.
Removed tests:
* TestOvsConnectivitySameNetwork.test_connectivity - basic connectivity
test covered by many other test cases,
* TestDhcpAgentNoHA.test_dhcp_assignment - basic test checking if
network was assigned to the DHCP agent - it's tested by many other
tests,
* TestLegacyL3Agent.test_namespace_exists - test which only checks that
qrouter namespace was created by the L3 agent, not needed really,
* TestLegacyL3Agent.test_east_west_traffic - covered already by many
scenario test cases,
* TestLegacyL3Agent.test_north_south_traffic - covered already by many
scenario test cases,
* TestBwLimitQoS.test_bw_limit_qos_policy_rule_lifecycle - covered
already by neutron-tempest-plugin scenario test,
* TestQoSWithL2Population - trivial test which isn't needed really,
* SecurityGroupRulesTest.test_security_group_rule_quota - already
covered by the neutron-tempest-plugin admin api test cases,
* TestSubnet.test_create_subnet_ipv4 - already tested in many scenario
test cases,
* TestSubnet.test_create_subnet_ipv6_slaac - already tested in tempest
scenario test case,
* TestTrunkPlugin.test_trunk_lifecycle - already covered by the scenario
test from the neutron-tempest-plugin
Additionally this patch removes monkeypatching of the init_handler
method from the neutron-ovs-agent. It was needed only due to the trunk
ports test and is not needed anymore.
Change-Id: Ifa438d30599ad7e627c85c772ffae9ae9226f7ea
(cherry picked from commit c1a0ceb86c64e6c312ad680b7051ccb931eb5fe3)
A non-vlan-transparent trunk parent port (tpt) should only forward
untagged frames. Earlier it was configured to forward anything (trunk
mode in ovs). This patch changes the trunk mode to access mode and
sets the trunk parent's tag explicitly to 0.
Change-Id: I4bcfe53fe87d7c9218dd0db9d7224bb323709a21
Closes-Bug: #2048785
(cherry picked from commit 27601f8eead444283e4d1c258298ac5afaff377f)
This patch is the initial implementation on the suggestion
from this patch[1].
The DHCP agent can query the existing `get_ports` RPC method because
this method is already exposed in the MetadataRpcCallback(server side)
which runs under the same topic(PLUGIN) and namespace(None). The benefit
here is that there is no change needed to the API, however it does
go against how we historically setup the RPC layer between a server and client.
[1] https://review.opendev.org/c/openstack/neutron/+/903572/comments/3d4e0453_4b4d2ab6
Merge Conflicts:
neutron/agent/linux/dhcp.py#L1216
OVN_METADATA_PREFIX is no present in ovn_constants, using 'ovnmeta-'
string literal instead
neutron/tests/unit/agent/linux/test_dhcp.py
Manually merged `get` method to the Dictable class
Related-Bug: #1982569
Change-Id: Icd7c55d2a5103bdbd90907b1dbfb9ccfe34c020a
(cherry picked from commit 637e7a50077f215dbaa25ebde6f6ca792ef4955b)
If the ``IpLinkCommand.set_netns`` fails, the method restores the
previous device namespace before raising the exception.
Closes-Bug: #2049590
Change-Id: I73b36ef161441b52922d888c11a144eafe8a7ed0
(cherry picked from commit e234a7aeab72958a74e5d9540253d48aa6915816)
Now the ``OVNAgentExtension`` class do not clear the agent API during
the extension initialization.
This patch also passes the agent object to the OVN agent extensions
as agent API. Any method required will be implemented directly on the
OVN agent class.
Closes-Bug: #2046939
Change-Id: Ia635ca1ff97c3db43a34d3dec6a7f9df154dfe28
(cherry picked from commit 86efc8be9934713ad79b3415b8b5b72bd475e01c)
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
(cherry picked from commit baaf240ce3f7802fe1431cc13913b9d93fc7f742)
When a router interface is created, the corresponding subnet gateway IP
is tested first [1]. If the subnet has no gateway IP, the router
interface cannot be created. This IP will be assigned to this port.
The Neutron API also prevents from modifying the subnet gateway IP
if assigned to a router interface [2]. However the API is not
preventing the subnet gateway IP deletion. This patch is adding
this check.
This patch is being tested in the neutron-tempest-plugin [3].
[1]de58c1b995/neutron/db/l3_db.py (L902-L904)
[2]de58c1b995/neutron/db/db_base_plugin_v2.py (L715)
[3]https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/904710
Closes-Bug: #2036423
Change-Id: I4c7b399a3a052749abdb88fb50be628ee91b63a0
(cherry picked from commit f9e40971e94e4fd239fcf7537b0f1200fbd4ee0f)
If the callback method ``OVNMechanismDriver.post_fork_initialize``
fails, the callback manager must raise an exception and finish the
process. If that happens in a Neutron worker, the
``oslo_service.service.Services`` class will restart the process.
The neutron-lib version is bumped to 3.8.1. It contains [1], needed
for this patch.
[1]https://review.opendev.org/c/openstack/neutron-lib/+/903334
Conflicts:
requirements.txt
Partial-Bug: #2036607
Change-Id: I2aca9a522bda2d69962369748b70fa9270fbe245
(cherry picked from commit bb1114c8b1b99834f2cb782dae796fa778ec2319)
normal network namespaces are bind-mounted to files under
/var/run/netns. If a process deleting a network namespace gets killed
during that operation there is the chance that the bind mount to the
netns has been removed, but the file under /var/run/netns still exists.
When the neutron-ovn-metadata-agent tries to clean up such network
namespaces it first tires to validate that the network namespace is
empty. For the cases described above this fails, as this network
namespace no longer really exists, but is just a stray file laying
around.
To fix this we treat network namespaces where we get an `OSError` with
errno 22 (Invalid Argument) as empty. The calls to pyroute2 to delete
the namespace will then clean up the file.
Additionally we add a guard to teardown_datapath to continue even if
this fails. failing to remove a datapath is not critical and leaves in
the worst case a process and a network namespace running, however
previously it would have also prevented the creation of new datapaths
which is critical for VM startup.
Closes-Bug: #2037102
Change-Id: I7c43812fed5903f98a2e491076c24a8d926a59b4
(cherry picked from commit 566fea3fed837b0130023303c770aade391d3d61)
When there is a backlog of notifications to be sent, it is possible
that ovsdb-server will merge insert and update notifications. Due
to this, we need to handle the situation where we see a Port_Binding
created with the chassis set.
Closes-Bug: #2017748
Change-Id: Idfae87cf6c60e9e18ede91ea20857cea5322738c
(cherry picked from commit a641e8aec09c1e33a15a34b19d92675ed2c85682)
As of Ib3c6f0dc01efd31430691e720ba23ccb4ede65fa, the
MaintenanceWorker checks for Chassis_Private table support and
uses it to remove duplicate Chassis/Chassis_Private entries. The
Chassis_Private table was not monitored in the BaseOvnSbIdl class
which the MaintenanceWorker uses.
Closes-Bug: #2049265
Change-Id: I711996b7644e80bc195833e4429e4d745728f9cf
The OVN fake resources factory method should return an instance
of the requested object, not a "type" metaclass object.
Closes-Bug: #2047049
Change-Id: I85c613dd628d7d2b67446d999b3e4d7b91eaf9fe
(cherry picked from commit e45c403676f30d8fe33977f61c027761427c2d41)
This method populates the SG rules in a dictionary. Each SG rule
inherits the "stateful" value of the SG. Prior to this patch, each
SG rule was isuing a database call to retrieve the SG register.
In this patch, the SG "stateful" retrieval is done in one database
query for all SG. That improves the performance of this method
reducing the database access to only one single call.
This improvement, as commented in the LP bug, affects to
ML2/LinuxBridge. ML2/OVS agent uses a cached RPC implementation
that not requires to perform any RPC call/database query.
Closes-Bug: #2045950
Change-Id: Iafd0419a1d1eeb25d5589edc2570ebf287450957
(cherry picked from commit 6b6abb9698318a0b5db09f0c4d30a47438a94643)
A new flag was added with [1], adapt unit tests with it.
Also drop an older compatibility check which is no longer
needed as neutron-lib>=3.8.0 already.
[1] https://review.opendev.org/c/openstack/neutron-lib/+/903334
Related-Bug: #2043959
Change-Id: I3b48b418d2d1293cdcf8fefb1b9ff7005bbebb29
(cherry picked from commit 95b4e8f41dbc56911369733a264a20c4affc1173)
Now the OVN agent implements a method ``__getitem__`` that retrieves,
from ``self.ext_manager``, a loaded extension by its name. The method
returns the instantiated extension object.
Closes-Bug: #2046892
Change-Id: Ibb6dc7c9150bf99639d5b6180356963998dc4e49
(cherry picked from commit fa46584af99c677489ee8e92eaabb25b801c1ce7)
The functional test "TestMaintenance.test_port_forwarding" is checking
the "registry.publish" call after calling
"create_floatingip_port_forwarding" and
"update_floatingip_port_forwarding". This patch makes this check
explicit for the expected call.
This patch is similar to [1].
[1]https://review.opendev.org/c/openstack/neutron/+/893028
Related-Bug: #2033387
Change-Id: I595dbd9b3abf413408fddf60735c0e8bd54e1d5c
(cherry picked from commit 2f637b2cb92dc37ef080eaf433fe580279136f32)