When ovn_router_indirect_snat = True, ml2/ovn will set a catch-all snat
rule for each external ip, instead of a snat rule per attached subnet.
NB: This option is global to cluster and cannot be controlled per
project or per router.
NB2: this patch assumes that 0.0.0.0/0 snat rules are properly handled
by OVN. Some (e.g. 22.03 and 24.03) OVN versions may have this scenario
broken. See: https://issues.redhat.com/browse/FDP-744 for details.
--
A long time ago, nested SNAT behavior was unconditionally enabled for
ml2/ovs, see: https://bugs.launchpad.net/neutron/+bug/1386041
Since this behavior has potential security implications, and since it
may not be desired in all environments, a new flag is introduced.
Since OVN was deployed without nested SNAT enabled in multiple
environments, the flag is set to False by default (meaning: no nested
SNAT).
In theory, instead of a config option, neutron could introduce a new API
to allow users to control the behavior per router. This would require
more work though. This granular API is left out of the patch. Interested
parties are welcome to start a discussion about adding the new API as a
new neutron extension to routers.
--
Before this patch, there was an alternative implementation proposed that
was not relying on 0.0.0.0/0 snat behavior implemented properly in OVN.
The implementation was abandoned because it introduced non-negligible
complexity in the neutron code and the OVN NB database.
See: https://review.opendev.org/c/openstack/neutron/+/907504
--
Closes-Bug: #2051935
Co-Authored-By: Brian Haley <haleyb.dev@gmail.com>
Change-Id: I28fae44edc122fae389916e25b3321550de001fd
The Neutron owned Static Routes created in the OVN database are marked
with the external_ids key neutron:is_static_route. This mark will be used
by the OVN DB sync tool to distinguish the Neutron created Static Routes
from those added externally; the second ones should not be altered during
the sync process. The static route update task runs only once during the
maintenance task, and if all entries are already configured, no action is
performed.
Related-bug: #2027742
Change-Id: I4226024cb4cfd85bdf4f717d42d48150cab22442
Since OVN 21.03.0 [1], ovn-controller no longer will try to reuse the
stale Chassis/Chassis_Private records but will try to create new ones.
If the stale records have no been manually deleted and ovn-controller
tries to register a new Chassis with the same values, the transaction will
fail.
[1]fc359bfe93
Closes-Bug: #2073613
Change-Id: I2f14558b0910fed03fe0243c4daa33947feeedcb
This patch introduces a new configuration option for OVN called
"broadcast_arps_to_all_routers". This option is responsible for
configuring the external networks with the 'broadcast-arps-to-all-routers'
configuration from OVN 23.06 and newer. By enabling this option (default)
OVN will flood ARP requests to all attached ports on a network. If
disabled, ARP requests are only sent to routers on that network if the
target MAC address matches. ARP requests that does not match a router
will only be forwarded to non-router ports.
Closes-Bug: #2071818
Change-Id: Id16b16113420e9f024e1936f9427824d711b6d30
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
This patch adds support for the MANAGER role in the Neutron API's
policies.
It also adds unit tests to cover MANAGER role privileges in all APIs.
This is implementation of the phase 3 of the Secure RBAC community goal
[1]
[1] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#phase-3
Change-Id: I377449050cb8aba56e167eba0981213831b8d7f2
The current comparison strategy is very time-consuming, and if
there are hundreds of thousands of security group rules, the
comparison time can still vary from several hours. The main
time-consuming operations are [1].
This patch is sorted first by security group rule ID and then
compared. The execution of sorting actions is relatively fast.
After actual measurement, the total time consumption is in the
minute level.
Partial-Bug: #2023130
[1] b86ca713f7/neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovn_db_sync.py (L285-L291)
Change-Id: If4c886d928258450aac31e12a4e26e0cbe2ace62
This allows deployment tooling to easily switch from passing a binary
path to passing a Python module path. We'll use it shortly.
Change-Id: I5350dff6be0daf1d4e5e5dfa4aab745b765436f7
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
There are three reasons to revert this patch.
1. It broke RPC push API for trunks because it added port db model to
event payload that is not serializeable.
2. It also broke the callback event payload interface, which requires
that all entries in .states attribute belong to the same core object.
To quote from neutron-lib,
```
# an iterable of states for the resource from the newest to the oldest
# for example db states or api request/response
# the actual object type for states will vary depending on event caller
self.states = ...
```
3. There is no good justification why ml2/ovn would not allow this
operation. The rationale for the original patch was to align the
behavior with ml2/ovs, but we don't such parity requirements. The 409
error that can be returned by the API endpoints is backend specific.
To quote api-ref,
```
409 The operation returns this error code for one of these reasons:
A system configuration prevents the operation from succeeding.
```
AFAIU there is nothing that prevents ml2/ovn to create a trunk in this
situation.
This will have to be backported in all supported branches (the original
patch was backported down to Wallaby).
Conflicts:
neutron/services/trunk/drivers/ovn/trunk_driver.py
This reverts commit 833a6d82cd705548130cdac73a88d388f52c7824.
Closes-Bug: #2065707
Related-Bug: #2022059
Change-Id: I067c2f7286b2684b67b4389ca085d06a93f856ce
Change non-harmful stack trace errors for dns_exc.DNSDomainNotFound and
dns_exc.DuplicateRecordSet to error log messages. This prevents the logs
from filling with stack traces where error messages would have been
sufficient enough.
Closes-Bug: #2042925
Change-Id: Icf1fff28bb560c506392f16c579de6d92cd56c23
If the Nova metadata service is unavailable, the requests.request()
function may raise a ConnectionError. This results in the upper code
returning a 500 HTTP status code to the user along with a traceback.
Let's handle this scenario and instead return a 503 HTTP status code
(service unavailable).
If the Nova service is down and is behind another proxy (such as
Nginx), then instead of a ConnectionError, the request may result in
receiving a 502 or 503 HTTP status code. Let's also consider this
situation and add support for an additional 504 code.
Closes-Bug: #2059032
Change-Id: I16be18c46a6796224b0793dc385b0ddec01739c4
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
Add file to the reno documentation build to show release notes for
stable/2024.1.
Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/2024.1.
Sem-Ver: feature
Change-Id: I7ab0ae40d0a79309d072105aceb97635d7338830
The "ha" API flag is now enabled for the OVN routers. Because of the
current implementation, this flag must be always "True". When a new
router is created, this flag is always set. If an OVN router is
explicitly created or updated with "--no-ha" (ha=False), the server
will raise an InvalidInput exception.
Depends-On: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/911081
Closes-Bug: #2020823
Change-Id: I60ff33680dd5397a226a9051d51bfb0701f862b5
This artifact is no longer used in the "Logical_Router" registers (in
the "options" field) to mark this "Logical_Router" as unhosted. A
"Logical_Router" is considered as unhosted if the gateway
"Logical_Router_Ports" have no "chassis" set.
This artifact is also used to create a "Gateway_Chassis" register
pointing to a inexisting invalid chassis called
"neutron-ovn-invalid-chassis". Any "Logical_Router_Port" not bound
to a chassis will have no value in "gateway_chassis" (NOTE1).
NOTE1: this is valid now with the current two OVN L3 schedulers that
use "gateway_chassis" to schedule the "Logical_Router_Port" of a
router. In a future, we can consider using "ha_chassis_group" for
scheduling.
Partial-Bug: #2052821
Related-Bug: #2019217
Change-Id: I12717936fe2bc188545309bacb8a260981f14c88
This is follow-up of 0a554b4f29a800694539b285c75eb7f8a2a69193 and fixes
the wrong option name mentioned in the release note file.
Change-Id: I5fd200c1352aaed8cff1d4a857967f5e32e45db7
api_workers=0 does not disable api workers but neutron-server still
launches one api worker. Rejecting 0 helps user notice that the value
they request in config files is not honored.
Also the other rpc workers options disable the corresponding workers
completely by setting these options to 0, so setting negative values
work but does not bring any special benefit.
Change-Id: Iac16b241c71ac1068c6fbea3cc792b74bfc66c03
Currently at least 1 rpc worker is launched even when a user requests
zero workers by setting rpc_workers=0. The setting of rpc_workers=0 is
used when ml2-ovn plugin is used without any additional agent, and in
this deployment pattern the single rpc worker is not at all used.
This change ensures no rpc worker is launched when rpc_workers options
is explicitly set to 0. This may be classified as a breaking change,
but is consistent with the earlier change[1] for rpc_workers=0.
[1] 3e1e2d63b3383d28c9a36b00000ab89caffa3829
Closes-Bug: #2052484
Change-Id: I878e50c3192ecd3b145ded0ab8394845a089696e
Currently both RpcReportsWorker and RpcWorker are launched with
the same process title("rpc worker"), and we can't distinguish one from
the other.
This changes the process title of RpcReportsWorker, so that we can
find the worker used by RpcReportsWorker, not by RpcWorker.
Change-Id: I610a00667762bbdd45bc72c5a865694b92cfd45a
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.
Related-Bug: #2028846
Change-Id: I398f3f676c59dc794cf03320fa45efc7b22fc003
