Synchronise 2026.1 with upstream#302
Open
github-actions[bot] wants to merge 16 commits into
Open
Conversation
The _is_vlan_project_network method in DNSExtensionDriverML2 was only checking the static network_vlan_ranges configuration from ml2_conf.ini, ignoring the dynamic ranges provided by the network-segment-range service plugin. This caused a KeyError when creating subnets or VMs on VLAN networks with segment ranges managed via the API. This fix updates the method to use VlanTypeDriver.get_network_segment_ranges(), which properly handles both static configuration and DB-based dynamic ranges when the network-segment-range plugin is enabled. Closes-Bug: #2140291 Signed-off-by: Kyuyeong Lee <kyu0.lee@samsung.com> Change-Id: I8f3a2b1c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a (cherry picked from commit cd8f88e)
Verify the port-forwarding floating IP id matches the child floating IP id so we satisfy the policy requirements for GET and PUT operations. Closes-bug: #2150121 Change-Id: Ie68e57da6222965e79d015a5568190d8bc29b9e8 Signed-off-by: Brian Haley <haleyb.dev@gmail.com> Assisted-by: Claude Sonnet 4.6
Several default port policies that require network ownership incorrectly included PROJECT_MANAGER. That rule checks the port project_id, not network ownership, so any project manager could perform those actions on shared/RBAC networks where they do not own the network. Remove PROJECT_MANAGER from the affected create/update port policies and rely on NET_OWNER_MEMBER or ADMIN_OR_NET_OWNER_MEMBER instead. Project managers who own the network remain authorized through the default Keystone role implication chain (manager implies member). Closes-Bug: #2152115 Assisted-By: Claude Composer 2.5 Signed-off-by: Rodolfo Alonso Hernandez <ralonsoh@redhat.com> Change-Id: I4e258d28cdf72adcc13fc9d03749256c65881c45 (cherry picked from commit d0f61db)
The ``OVNL3RouterPlugin`` registers OVN OVSDB monitor events during ``_post_fork_initialize``. That callback is also invoked from neutron-periodic-workers and other non-API processes, where the OVN IDL connections are not initialized. Checking OVN readiness before filtering by worker type raised ``MechanismDriverOVNNotReady`` and blocked worker startup. Return early when the trigger is not a Neutron API ``WorkerService``, and only then validate OVN readiness and register monitor events. Conflicts: neutron/services/ovn_l3/plugin.py Related-Bug: #2154192 Signed-off-by: Rodolfo Alonso Hernandez <ralonsoh@redhat.com> Change-Id: I9e43fdb06ce7868e5fa699657d8da9a4aa4d02fb (cherry picked from commit b6d260e)
The ``_is_tunnel_project_network`` method in ``DNSExtensionDriverML2`` was only checking the static tunnel ranges from ml2_conf.ini, ignoring the dynamic ranges provided by the ``network-segment-range service`` plugin. When segment ranges are managed via the API, external DNS eligibility for tenant tunnel networks could be wrong. Update the method to use the ML2 tunnel type driver's ``get_network_segment_ranges()``, which handles both static configuration and DB-based ranges when the network-segment-range plugin is enabled. Closes-Bug: #2154266 Related-Bug: #2140291 Assisted-By: Cursor Composer 2.5 Signed-off-by: Rodolfo Alonso Hernandez <ralonsoh@redhat.com> Change-Id: I5d96efa626d18b7589cf2563fdac3a8d399a69a8 (cherry picked from commit 6913303)
The openvswitch firewall driver has got OF rules to mark some connections as invalid using mark CT_MARK_INVALID in conntrack. Later packets which belongs to such invalid connection are dropped by different OF rules in br-int. The problem is that such conntrack entries were cleaned for each of the ports for which filters were updated, even with deferred apply on. In such case new OpenFlow rules are applied in deferred way after all ports are processed by the agent. That could lead to the situation where conntrack entries to mark some kind of connection as invalid was deleted by the fw driver, but new OF rules were not yet applied in the br-int. If during that time the same packets were still flowing to/from the port, new conntrack entry to mark such packets would be added back and that would not be cleaned after OF rules were actually applied on the `br-int` bridge. This patch fixes that issue be deferring cleanup of the conntrack entries for all ports to be done after OF rules are actually updated in `br-int`. Assisted-by: claude-opus-4.6 Closes-bug: #2154561 Change-Id: I8655da7f7a0cf033ce4a7145f5345195881238e5 Signed-off-by: Slawek Kaplonski <skaplons@redhat.com> (cherry picked from commit 8fde7d4)
…plied" into stable/2026.1
Ports with mac=['unknown'] (e.g. network:dhcp ports without port security) cause the metadata agent to crash with a ValueError when iterating chassis ports during datapath provisioning. Add an explicit check for mac=['unknown'] alongside the existing empty-MAC guard to skip these ports gracefully. Closes-Bug: #2150434 Assisted-By: Claude Opus 4.6 Change-Id: I966c7a22eca589770793a0ef30c3bbc591c41e41 Signed-off-by: Eduardo Olivares <eolivare@redhat.com> (cherry picked from commit fecac2c)
Singleton conntrack helper API operations (GET/PUT/DELETE on
/routers/{router_id}/conntrack_helpers/{id}) authorized the request
against the URL ``router_id`` but loaded the helper by child ID only.
A project member with access to one router could therefore operate on
another tenant's helper by reusing its UUID in the path.
Validate that the loaded helper's ``router_id`` matches the URL
``router_id`` before returning, updating, or deleting it, following
the same pattern used for floating IP port forwarding sub-resources.
Closes-Bug: #2152109
Assisted-By: Claude Opus 4.6
Signed-off-by: Rodolfo Alonso Hernandez <ralonsoh@redhat.com>
Change-Id: Icb4a7d2e8f1c35609d8a4b7e2f6c9d0a1b3e5f78
(cherry picked from commit bc8a554)
The operation for these actions is PUT, not POST. Closes-Bug: #2156054 Signed-off-by: Rodolfo Alonso Hernandez <ralonsoh@redhat.com> Change-Id: Iec4b8ddf3717ddc781acfb46ada81839f853bdea (cherry picked from commit 8ccf3f9)
When a VIF port is picked up by the OVS agent ``rpc_loop`` before OVS has assigned it a valid ofport (the underlying TAP device may not yet exist), ``port_alive()`` and ``port_dead()`` pass the invalid value (``[]`` or ``-1``) through to ``uninstall_flows()`` / ``drop_port()``. The resulting OpenFlow FlowMod with ``in_port=None`` causes os-ken's ``send_msg`` to hang until the ``of_request_timeout`` (300 s) fires, blocking the ``rpc_loop`` for the entire duration and preventing all subsequent port processing. Guard ``port_alive()``, ``port_dead()`` and ``treat_vif_port()`` so they return early when the ofport is unassigned or invalid. ``treat_vif_port()`` returns False so the port is not marked as bound; the OVSDB monitor will detect the ofport change on a later iteration and re-trigger processing. Closes-Bug: #2155883 Assisted-By: Claude Opus 4.6 Signed-off-by: Rodolfo Alonso Hernandez <ralonsoh@redhat.com> Change-Id: Ic137f8a2862794c3c7ac670e643ca532873e474b (cherry picked from commit 8a4a4b1)
When a port is inserted into OVS, the kernel may transiently assign ``ofport=-1`` (``INVALID_OFPORT``) before settling on a valid value. Previously, ``_process_port`` only deferred ports with ``UNASSIGNED_OFPORT`` (``[]``), so a port arriving with ``ofport=-1`` was immediately added to the processing pipeline. Patch [1] then correctly skipped OF operations in ``treat_vif_port`` for such ports but never re-queued them, which meant the ``network-vif-plugged`` event was never sent to Nova, causing a 300 s VIF-plug timeout. Extend the ``_process_port`` check to also defer ``INVALID_OFPORT`` ports via the existing ``ports_not_ready_yet`` mechanism. On the next ``rpc_loop`` iteration the port attributes are re-read from OVS; if the ofport is now valid the port is processed normally, otherwise it is deferred again. [1]https://review.opendev.org/c/openstack/neutron/+/992423 Closes-Bug: #2155883 Assisted-By: Claude Opus 4.6 Signed-off-by: Rodolfo Alonso Hernandez <ralonsoh@redhat.com> Change-Id: I9fbc8f75f8084461901a004dfcb07e42f76db62b (cherry picked from commit 7ebcce0)
When a service plugin package (e.g. neutron-fwaas, neutron-vpnaas,
networking-sfc) is installed but its service plugin is not configured
in ``service_plugins``, the quota details API endpoint
(GET /v2.0/quotas/{project_id}/details) returns a 500 Server Error.
The installed package registers quota resources (e.g. firewall_group,
firewall_policy, firewall_rule) at import time via
``resource_helper.build_resource_info(register_quota=True)``. When the
quota details endpoint iterates over all registered resources to
count usage, it calls ``_count_resource()`` which looks for a plugin
that provides ``get_<collection>_count`` or ``get_<collection>``.
Since the service plugin is not loaded, no plugin supports counting
those resources, and a ``NotImplementedError`` is raised.
Catch the ``NotImplementedError`` in
``DbQuotaDriver.get_detailed_project_quotas()`` and skip the resource
instead of letting the exception propagate as a 500 error. Also
guard the project-specific limit update loop against skipped
resources.
Closes-Bug: #2155846
Assisted-By: Claude Opus 4.6
Signed-off-by: Rodolfo Alonso Hernandez <ralonsoh@redhat.com>
Change-Id: I923e90279edf3de3fa85c83fd46e1b5dec0468de
With tunneling disabled (enable_tunneling=False), there is no br-tun and self.tun_br is None. _restore_local_vlan_map(), called from __init__(), calls self.tun_br.get_flood_to_tun_ofports() unconditionally for every integration-bridge port that carries a net_uuid, so the agent crashes: AttributeError: 'NoneType' object has no attribute 'get_flood_to_tun_ofports' The branch is only reached once the agent has populated net_uuid on the ports, so the crash hits on agent restart and recurs on every restart, preventing the agent from restoring dataplane flows until manual recovery. Skip the flood-port restore when tunneling is disabled, leaving tun_ofports as an empty set as for ports with no tunnel flood entries. Closes-Bug: #2156566 Change-Id: I4741480f8a7fbce51f521579e78d5687773c29b8 Signed-off-by: Seyeong Kim <seyeong.kim@canonical.com> (cherry picked from commit 92181b3)
github-actions
Bot
added
automated
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains a snapshot of 2026.1 from upstream stable/2026.1.