Commit Graph

994 Commits

Author SHA1 Message Date
Anton Kurbatov 6395b4fe8e Fixing the 500 HTTP code in the metadata service if Nova is down
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
2024-03-26 12:14:08 +00:00
Robert Breker 5e1188ef38 Enhance IptablesFirewallDriver with remote address groups
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
2024-03-20 22:20:45 +00:00
OpenStack Release Bot 6330543517 Update master for stable/2024.1
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
2024-03-15 14:50:30 +00:00
Zuul e8468a6dd6 Merge "[OVN] Enable "ha" API flag for OVN routers" 2024-03-07 22:32:47 +00:00
Zuul 63d6079d1c Merge "reno: Update master for unmaintained/victoria" 2024-03-07 16:33:04 +00:00
Zuul 48fa82f879 Merge "reno: Update master for unmaintained/wallaby" 2024-03-07 16:32:59 +00:00
Rodolfo Alonso Hernandez b8953b543a [OVN] Enable "ha" API flag for OVN routers
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
2024-03-06 18:42:29 +00:00
OpenStack Release Bot 33044d5e04 reno: Update master for unmaintained/xena
Update the xena release notes configuration to build from
unmaintained/xena.

Change-Id: I15e8648c15c60e77b7892869a7a0fd9c5c0589aa
2024-03-06 12:19:45 +00:00
OpenStack Release Bot 499988db7f reno: Update master for unmaintained/wallaby
Update the wallaby release notes configuration to build from
unmaintained/wallaby.

Change-Id: I0aa342b9d1206c2e9cd6746240b8be7055614018
2024-03-06 12:11:14 +00:00
OpenStack Release Bot 63e976b620 reno: Update master for unmaintained/victoria
Update the victoria release notes configuration to build from
unmaintained/victoria.

Change-Id: Icad36b47dcd19ea1bf7b05077473d1a1655a739f
2024-03-06 12:01:46 +00:00
Zuul 5c187e8dab Merge "Add release notes for l3-ext-gw-multihoming and adjacent features" 2024-03-05 17:26:27 +00:00
Zuul afe001cf63 Merge "[OVN] Remove OVN_GATEWAY_INVALID_CHASSIS artifact" 2024-03-01 20:38:48 +00:00
Rodolfo Alonso Hernandez fa3223bb9d [OVN] Remove OVN_GATEWAY_INVALID_CHASSIS artifact
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
2024-03-01 07:03:26 +00:00
Zuul 1651631561 Merge "Replace CRLF by LF" 2024-03-01 06:13:48 +00:00
Zuul bbaa3f55c5 Merge "Fix wrong option name in release note" 2024-02-13 08:18:05 +00:00
Zuul 267690b505 Merge "Set minumum boundary for workers" 2024-02-13 01:03:40 +00:00
Zuul 558fc96bdd Merge "Completely disable rpc workers when rpc_workers=0" 2024-02-12 21:03:08 +00:00
Takashi Kajinami 027ad4624d Fix wrong option name in release note
This is follow-up of 0a554b4f29 and fixes
the wrong option name mentioned in the release note file.

Change-Id: I5fd200c1352aaed8cff1d4a857967f5e32e45db7
2024-02-12 23:10:16 +09:00
Takashi Kajinami 78e8f1dca0 Set minumum boundary for workers
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
2024-02-12 06:28:23 +00:00
Takashi Kajinami b38f72b212 Completely disable rpc workers when rpc_workers=0
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] 3e1e2d63b3

Closes-Bug: #2052484
Change-Id: I878e50c3192ecd3b145ded0ab8394845a089696e
2024-02-12 06:28:07 +00:00
Zuul a2e137008b Merge "[OVN] Warn about invalid OVN and FIP PF config during start of Neutron" 2024-02-09 17:55:17 +00:00
Zuul 9155a2512d Merge "Use different process title for RpcReportsWorker and RpcWorker" 2024-02-09 07:16:49 +00:00
Takashi Kajinami babb63275d Use different process title for RpcReportsWorker and RpcWorker
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
2024-02-08 20:12:09 +00:00
Zuul 33b5af695b Merge "[OVN] Add ``subnetpool-prefix-ops`` extension to ML2/OVN mech driver" 2024-02-08 11:22:22 +00:00
Slawek Kaplonski ce53fb55ad [OVN] Warn about invalid OVN and FIP PF config during start of Neutron
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
2024-02-06 14:46:48 +00:00
OpenStack Release Bot a097f363d1 reno: Update master for unmaintained/yoga
Update the yoga release notes configuration to build from
unmaintained/yoga.

Change-Id: Ib5c2e8376700f6a0a5c8207f31f6d8592f900382
2024-02-05 16:46:39 +00:00
Zuul 737f16715a Merge "[OVN] Add the bridge name and datapath type to the port VIF details" 2024-01-30 11:57:59 +00:00
Rodolfo Alonso Hernandez 1600d54175 [OVN] Add ``subnetpool-prefix-ops`` extension to ML2/OVN mech driver
Related-Bug: #1792901
Change-Id: I6b2e86cd252c345b25583651152009baa3320f19
2024-01-30 06:34:08 +00:00
Zuul 2072bb4269 Merge "[ovn] AZs distribution in L3 port scheduler" 2024-01-29 21:23:25 +00:00
Takashi Kajinami bf83de893f Replace CRLF by LF
... because LF is now commonly used as newline code.

Change-Id: Iaeb970c3dc335c416329e9ec688d4a97898729c6
2024-01-27 12:31:49 +09:00
Yann Morice a29ea3724e [ovn] AZs distribution in L3 port scheduler
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
2024-01-26 15:22:34 +01:00
Bence Romsics 27601f8eea Set trunk parent port as access port in ovs to avoid loop
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
2024-01-24 14:42:13 +01:00
Zuul 5ce17647c6 Merge "Router flavors and service type for OVN" 2024-01-17 20:27:17 +00:00
Miguel Lavalle 49366ecada Router flavors and service type for OVN
Support is added to the OVN L3 service plugin for the router
flavors and service type framework

Partial-Bug: #2020823
Change-Id: If40d7b39e7b59a39ff7622bd823dbdb14bfc69d2
2024-01-17 09:33:07 -06:00
Felix Huettner 3d5d82a197 ovn-l3: reschedule lower priorities
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
2024-01-17 12:04:09 +01:00
Zuul 3ced5956a7 Merge "Forbid the subnet gateway IP deletion if a router interface is attached" 2024-01-15 19:45:23 +00:00
Rodolfo Alonso Hernandez f9e40971e9 Forbid the subnet gateway IP deletion if a router interface is attached
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
2024-01-17 13:33:41 +00:00
Rodolfo Alonso Hernandez baaf240ce3 [OVN] Add the bridge name and datapath type to the port VIF details
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
2024-01-14 15:51:07 +00:00
Zuul dce8c34dd2 Merge "Add a "port" child table "porthardwareoffloadtype"" 2024-01-09 13:21:08 +00:00
Zuul 97b84180b2 Merge "[OVN] Update release note section to "fixes" for LP#2036705" 2024-01-03 10:15:36 +00:00
Zuul ef3089547b Merge "Fix IGMP inconsistency across drivers" 2023-12-18 13:19:07 +00:00
Zuul cf1d5ea35c Merge "[ovn] Add support for IPv6 metadata" 2023-12-15 13:10:13 +00:00
Lucas Alvares Gomes 114ca0f1be Fix IGMP inconsistency across drivers
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>
2023-12-15 09:05:19 +00:00
Zuul 0bb22b355e Merge "[OVN] Add baremetal support without Neutron DHCP agent for IPv6" 2023-12-12 03:32:18 +00:00
Daniel Alvarez Sanchez d9c8731af3 [ovn] Add support for IPv6 metadata
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>
2023-12-08 17:15:42 -05:00
Zuul a0ef04d3b7 Merge "[OVN] Remove backwards compatibility with OVN < v20.09" 2023-12-08 22:08:24 +00:00
Zuul 82994ad8b1 Merge "Add a new option to enable signals" 2023-12-08 18:32:12 +00:00
Rodolfo Alonso Hernandez a579e504e9 [OVN] Remove backwards compatibility with OVN < v20.09
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
2023-12-04 09:20:57 +00:00
Zuul fd98ee34e1 Merge "Add support for OVN MAC_Binding aging" 2023-12-02 01:24:41 +00:00
Zuul 420ad91bcb Merge "Remove ovs_integration_bridge configuration option" 2023-12-01 18:20:23 +00:00