support microovn installed after openstack-hypervisor#171
Merged
gboutry merged 2 commits intocanonical:stable/2024.1from Apr 7, 2026
Merged
Conversation
Add a network.ovs-managed-by snap config option (values: auto, microovn, hypervisor) so the charm can declare OVS management mode independently of the ovn-chassis plug connection state. Previously is_ovs_external() relied solely on snapctl is-connected ovn-chassis, which returns False until microovn is installed and the plug is connected. This caused the snap to start its internal OVS services even when the operator intended microovn to manage OVS. Changes: - Add OVS_MANAGED_BY_AUTO/MICROOVN/HYPERVISOR constants and _OVS_MANAGED_BY module-level cache - Add _set_ovs_managed_by(snap) called at the top of configure() to read and cache network.ovs-managed-by before any is_ovs_external() calls; invalid values fall back to 'auto' with a warning - Update is_ovs_external() to honour the config value first, only falling through to the plug check in 'auto' mode - Add _external_ovs_ready(snap) that checks whether the microovn OVS socket path exists, mirroring the existing _internal_ovs_ready() - Extend configure() deferral logic with external_ovs_deferred: when network.ovs-managed-by=microovn but microovn is not yet installed (socket absent), skip OVN TLS and networking configuration instead of hanging on ovs-vsctl commands; the hook retries automatically on the next snap set invocation - Add unit tests for all new code paths (cherry picked from commit b1ac96e)
When openstack-hypervisor and microovn are deployed simultaneously,
snapd fires the configure hook immediately after snap install — before
the charm has applied any snap config. At that point
network.ovs-managed-by is still 'auto' and the ovn-chassis plug is not
yet connected, so is_ovs_external() returns False. This caused
_ensure_internal_ovs_services to start ovs-vswitchd, which creates the
system@ovs-system kernel datapath. When microovn subsequently tries to
initialise OVS it finds the datapath already in use and fails.
The same issue affects the second configure hook, triggered when the
charm's own install hook calls `snap set network.ovs-managed-by=auto`,
since the identity URL is still the placeholder at that point too.
Fix: before calling _ensure_internal_ovs_services, check whether the
charm has applied its identity configuration. The guard defers OVS
startup when BOTH identity.auth-url is still the placeholder default
("http://localhost:5000/v3") AND identity.username is unset (None).
Checking both fields ensures the guard still clears correctly for
operators that legitimately run Keystone at http://localhost:5000/v3,
since those deployments will always set identity.username. Once either
condition is no longer true the guard clears and _ensure_internal_ovs_services
runs normally.
The guard is only active when network.ovs-managed-by is 'auto'. When
explicitly set to 'hypervisor' the operator's intent is unambiguous and
ovs-vswitchd is started immediately regardless of identity state.
(cherry picked from commit e72c732)
gboutry
approved these changes
Apr 7, 2026
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
2 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.
Backport of
#167
#168