If a ML2/SR-IOV port is disabled (status=DOWN), it will have precedence
on the VF link state value over the "auto" value. That will stop any
transmission from the VF.
Closes-Bug: #2078789
Change-Id: I11d973d245dd391623e501aa14b470daa780b4db
(cherry picked from commit 8211c29158d6fc8a1af938c326dfbaa685428a4a)
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
(cherry picked from commit ac15191f88a63bd5e0510c3602fb6d19c9ac1c92)
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
(cherry picked from commit 6395b4fe8ed99855853587fa93cb59fd2691aed5)
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)
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
Update l3 ovn schedulers (chance, leastloaded) to ensure that LRP gateways are distributed over chassis in the different eligible AZs.
Previous version already ensure that LRP gateways were scheduled over chassis in eligible AZs. But, depending on the deployment characteristics, all these chassis could be in the same AZ. In some use-cases, it could be needed to have LRP gateways in different AZs to be resilient on failures.
This patch re-order the list of eligible chassis to add a priority on selecting chassis in different AZs.
This should provide a solution for users who need to have their router gateways scheduled on chassis from different AZs.
Closes-Bug: #2030741
Change-Id: I72973abbb8b0f9cc5848fd3b4f6463c38c6595f8
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
Support is added to the OVN L3 service plugin for the router
flavors and service type framework
Partial-Bug: #2020823
Change-Id: If40d7b39e7b59a39ff7622bd823dbdb14bfc69d2
if a gateway chassis is removed we previously only plugged the hole it
left in the priorities of the lrps. This can lead to bad choice since we
are bound by all other currently used chassis.
By allowing us to also reschedule the lower priorities we get
significantly more freedom in choosing the most appropriate chassis and
prevent overloading an individual one.
As an example from the new testcase:
previously we would have had all prio 2 schedules on chassis3, but with
this change now this distributes better also to chassis4.
Partial-Bug: #2023993
Change-Id: I786ff6c0c4d3403b79819df95f9b1d6ac5e8675f
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
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
Prior to this patch, ML2/OVS and ML2/OVN had inconsistent IGMP
configurations. Neutron only exposed one configuration option for IGMP:
igmp_snooping_enabled.
Other features such as IGMP flood, IGMP flood reports and IGMP flood
unregistered were hardcoded differently on each driver (see LP#2044272
for a more details).
These hardcoded values has led to many changes over the years tweaking
them to work on different scenarios but they were never final because
the fix for one case would break the other.
This patch introduces 3 new configuration options for these other IGMP
features that can be enabled or disabled on both backends. Operators
can now fine tune their deployments in the way that will work for them.
As a consequence of the hardcoded values for each driver we had to break
some defaults and, in the case of ML2/OVS, if operators want to keep
things as they were before this patch they will need to enable the new
mcast_flood and mcast_flood_unregistered configuration options.
That said, the for ML2/OVS there was also an inconsistency with the help
string of igmp_snooping_enabled configuration option as it mentioned
that enabling snooping would disable flooding to unregistered ports but
that was not true anymore after the fix [0].
[0] https://bugs.launchpad.net/neutron/+bug/1884723
Closes-Bug: #2044272
Change-Id: Ic4dde46aa0ea2b03362329c87341c83b24d32176
Signed-off-by: Lucas Alvares Gomes <lucasagomes@gmail.com>
This patch adds support for IPv6 metadata service in ML2/OVN.
The changes include:
- Add the 'fe80::a9fe:a9fe/128' address to the interface of the
ovnmeta- namespace so that it's reachable from the guests
- Identify the port of the VM by looking up the source MAC address
of the metadata request
- Restarts the haproxy instances to honor the configuration changes
upon start of the metadata agent. In particular, haproxy now also
binds on the 'fe80::a9fe:a9fe' address
When the VM requests metadata from its LLA, the traffic will reach
the ovnmeta namespace associated to its network.
The IPv6 metadata tests are passing and enabled in Tempest by
this patch:
https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/894027
Besides, this patch ensures that the link-local address of the
metadata interface is present so that the metadata IPv6 endpoint
is reachable. It also fixes a bug that was causing the wrong LLA
to be present as the interface was set `up` first prior to changing
the MAC address. Now this order is inverted so that the proper LLA
is configured.
Change-Id: Idcef6de33ed2a73cb3c426db1c55fa9cd06de63f
Signed-off-by: Daniel Alvarez Sanchez <dalvarez@redhat.com>
This patch removes the compatibility with OVN under v20.09. That
implies the OVN Southbound definition has "Chassis_Private" table.
Any previous check is removed from the code.
This patch also adds a sanity check, testing that the OVN Southbound
database definition is greater or equal to 2.9.0 [1].
The testing OVN NB and SB schemas are updated to the files contained in
OVN v22.09. The new testing NB schema version is 6.3.9; the new testing
SB schema version is 20.25.0.
[1]4adc10f581
Closes-Bug: #2002839
Change-Id: Iec8854749a1df81eb6a7154d3f951e176c69156d