Synchronise 2026.1 with upstream - #344
Open
github-actions[bot] wants to merge 7 commits into
Open
Conversation
The bridge is an abstraction between the Neutron and the BGP worlds (legacy provider bridge). The name is defined in local OVS with neutron-bgp-interconnect-bridge key. The bridge tracks its ofports to the br-int and keeps flows peer-to-peer while changes the destination mac whenever the traffic goes from Neutron towards the BGP. This is to make sure all packets coming from Neutron get to the main BGP router. Assisted-By: Claude Sonnet 4.6 Change-Id: I832c30a124ca32941ab8048b00a1e41b93ba67a6 Signed-off-by: Jakub Libosvar <libosvar@redhat.com> (cherry picked from commit 77fcf36)
link_network_ha_chassis_group() unconditionally rebuilds a network's unified HA_Chassis_Group from the router gateway port's Gateway_Chassis registers, even when that list is empty -- always the case for tunnelled (e.g. VXLAN) gateways, which are pinned to a chassis via the Logical_Router "chassis" option instead. This wiped the network's HA_Chassis_Group to zero members any time the gateway port changed, even if it had already been correctly populated some other way, breaking north/south routing and ARP for every external/baremetal port on that network. Leave the HA_Chassis_Group alone when Gateway_Chassis is empty, instead of overwriting it with one. stable/2026.1 only: master picked up an equivalent check as a side effect of migrating Logical_Router_Port gateway-chassis tracking to HA_Chassis_Group (commit 03d6a84 / I8bfcc2b77acb89b78b13563aa4ca9fe3f19cb076), which can't be backported here without the rest of that migration which is feature work, not so not a backport candidate. This is the minimal, targeted equivalent for the Gateway_Chassis column this branch still uses. The tests on the other hand were not part of that original change and are a backport of I1c1450c0be4d4cda732c339720a66c5af80542ad to verify the behavior. Assisted-by: Claude Opus 4.8 Closes-Bug: #2162072 Related-Bug: #2125553 Change-Id: I3b3e41563a0de2e257a21bdfab2b6c667ca7e05b Signed-off-by: Doug Goldstein <cardoe@cardoe.com>
The option [1] makes ovn-controller to create the blackhole routes only for IPs that are local to the chassis. Closes-Bug: #2148236 [1] https://github.com/ovn-org/ovn/blob/c9af703c618a20eb043537c7e991e32e1a3a1afe/ovn-nb.xml#L3544 Change-Id: I3de4141b3b2dc5f97d682ae976a4ff55a69941c7 Signed-off-by: Jakub Libosvar <libosvar@redhat.com> (cherry picked from commit ea71266)
…sis" into stable/2026.1
Two OVSDB monitor event classes (``PortBindingUpdateVirtualPortsEvent``
and ``LogicalSwitchPortUpdateLogicalRouterPortEvent``) create a single
Neutron admin_context in ``__init__`` and reuse it across all ``run()``
and ``match_fn()`` invocations. This is unsafe because:
1. The downstream plugin method update_virtual_port_parent_host is
decorated with ``@transaction_guard``, which raises RuntimeError if
the context session is still active from a previous call. Under
eventlet, the shared session can retain residual active state
between sequential calls on the ovsdbapp dispatch greenthread.
2. When the RuntimeError fires, ovsdbapp catches it silently in the
dispatch thread (LOG.exception). The VIP NB revision and
external_ids are never updated, causing ovn-northd re-processing
delays that prevent LSP.up propagation for other ports, leading
to 60-second port-status timeouts in functional tests.
3. For ``LogicalSwitchPortUpdateLogicalRouterPortEvent``, the shared
context is also used in ``match_fn()``, which runs synchronously in
the IDL connection thread. A stale session can break DB queries
during event matching.
Fix by creating a fresh admin_context in each ``run()`` and
``match_fn()`` invocation, matching the pattern used everywhere else
in Neutron (e.g., ``OVNMechanismDriver.set_port_status_up``).
Conflicts:
neutron/plugins/ml2/drivers/ovn/mech_driver/ovsdb/ovsdb_monitor.py
NOTE(backport): this branch does not contain the
``LogicalSwitchPortEvent`` base class refactor, and
``PortBindingUpdateVirtualPortsEvent`` here does not use an
admin_context at all - its ``run()`` calls
``self.driver.update_virtual_port_host()``, which takes no context.
Only the ``LogicalSwitchPortUpdateLogicalRouterPortEvent`` part of the
original change is applicable and has been kept. The two unit tests
covering ``PortBindingUpdateVirtualPortsEvent.run()`` were dropped for
the same reason (they assert on
``_ovn_client.update_virtual_port_parent_host``, which does not exist
on this branch).
Closes-Bug: #2152169
Assisted-By: claude-4.6-opus-high
Signed-off-by: Rodolfo Alonso Hernandez <ralonsoh@redhat.com>
Change-Id: I294c7f229c5e871ad06fe754de9fb7f335ec9005
(cherry picked from commit c24a0f1)
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
3 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.