This change enhances the IptablesFirewallDriver with support for remote
address groups. Previously, this feature was only available in the
OVSFirewallDriver. This commit harmonizes the capabilities across both
firewall drivers, and by inheritance also to OVSHybridIptablesFirewallDriver.
Background -
The Neutron API allows operators to configure remote address groups [1],
however the OVSHybridIptablesFirewallDriver and IptablesFirewallDriver do
not implement these remote group restrictions. When configuring security
group rules with remote address groups, connections get enabled
based on other rule parameters, ignoring the configured remote address
group restrictions.
This behaviour undocumented, and may lead to more-open-than-configured network
access.
Closes-Bug: #2058138
Change-Id: I76b3cb46ee603fa5e829537af41316bb42a6f30f
(cherry picked from commit 5e1188ef38da3f196aadf82a3842fa982c9a0c83)
- test_update_subnet_dhcp_options_in_ovn_ipv6_not_change
- test_enable_subnet_dhcp_options_in_ovn_ipv6
This tests will fail if host where unit tests has ipv6 dns_servers
configured. This patch mocks get_system_dns_servers to avoid tests
to look at the host configuration.
Closes-Bug: #2056778
Change-Id: I2e703ab4b63c90d7a14f0dc41d37b0a98163bce0
(cherry picked from commit 2a196fefd4a8a0c15176fe87d88b05d1690ab5fa)
The VETH pair between the metadata namespace and the local OVS now
has the same MTU as the network associated to this metadata service.
The "LSP.external_ids" field has a new key defined: "neutron:mtu".
This is the value of the network MTU.
This patch does not update the previous metadata datapaths nor the
existing LSP. This change will affect only to new created ports
and the corresponding metadata datapaths.
Conflicts:
neutron/agent/ovn/metadata/agent.py
Closes-Bug: #2053274
Change-Id: I7ff300e9634e5e3fc68d70540392109fd8b9babc
(cherry picked from commit 47b4d14955451c320ce612e4e2e7d0a896e2fe36)
(cherry picked from commit 101898fde869a5f530580d1c69c52cdc4a33cd98)
In both neutron-metadata and neutron-ovn-metadata agents we should
ensure that haproxy service spawned for network/router is actually
active before moving on.
This patch adds that check and this is similar to what was already
implemented some time ago for the dnsmasq process spawned by the dhcp
agent.
Related-Bug: #2052787
Change-Id: Ic58640d89952fa03bd1059608ee6c9072fbaabf5
(cherry picked from commit 2f7f7c2fc29d0ac26b5ff9d82867952a40f0fa1b)
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.
Conflicts:
neutron/tests/functional/services/ovn_l3/test_plugin.py
Related-Bug: #2019217
Change-Id: I140c22899ea3b0240f8c30902fc2dc7055914a18
(cherry picked from commit d55c591ecde2f6cc4c2cea64fb21a75b6343cd5a)
After some interface operations (in particular the
``IpLinkCommand.set_ns`` operation), the network interface is
temporarily not present in the destination namespace. This patch
retries the interface "ip link set|show" command in that case.
Related-Bug: #1961740
Change-Id: I5a57cfc71ad59f1fe9ea65e19b1a32314d798729
(cherry picked from commit 016f5187a5503b835cd6803c5d8fe6f05091df12)
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)
(cherry picked from commit 874855773863e75f2f9f5f6e50fd48581a54be2e)
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)
(cherry picked from commit 3eaa326a7a86d46f5139d6f3c017e6128b391881)
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)
(cherry picked from commit 1c6d3d448d419d6176647dc0e50760c19d3fefcb)
Do not allow the subnet cidr of :: to be used when
creating a subnet, except in the case IPv6 prefix
delegation has been specified in the request.
Conflicts:
neutron/tests/unit/db/test_db_base_plugin_v2.py
Closes-bug: #2028159
Change-Id: I480e9a117513996f3c070acd4ba39c2b9fe9c0f1
(cherry picked from commit 2f0011194012a2482f79603c310028736e9ff3c8)
Grenade skip level jobs reference stable/yoga but that branch
was renamed to unmaintained/yoga
Change-Id: Ifdfa194a95a39c63ec61f2afe030fed108de5a77
Related-Bug: #2052915
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)
(cherry picked from commit 0b5ffd1e1b2259e73021029f32b313cc08a82239)
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
Related-Bug: #1982569
Change-Id: Icd7c55d2a5103bdbd90907b1dbfb9ccfe34c020a
(cherry picked from commit 3b6e642a670462539a15b91dd2a430ec2ecaa1a5)
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.
NOTE: update n-lib version
The neutron-lib version is bumped to 3.4.2. It contains [1], needed
for this patch.
[1]https://review.opendev.org/c/openstack/neutron-lib/+/903335
Conflicts:
requirements.txt
Partial-Bug: #2036607
Change-Id: I2aca9a522bda2d69962369748b70fa9270fbe245
(cherry picked from commit bb1114c8b1b99834f2cb782dae796fa778ec2319)
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)
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)