Fix 2025.2 upgrade blockers (group_vars, proxysql, horizon)#294
Merged
Conversation
all/001-kolla-defaults.yml mirrors upstream kolla-ansible's global
group_vars/all but is synced to stable/2025.1 and never picked up
several variables added during the 2025.2 cycle. Because OSISM's
defaults replace kolla-ansible's own group_vars/all at deploy time,
those variables are undefined on a 2025.2 deploy/upgrade, aborting the
service tasks that reference them (keystone is simply the first wall
the upgrade reaches).
Add, verbatim from upstream stable/2025.2:
- keystone_listen_port: used by the keystone role's uWSGI config
(keystone_wsgi_provider defaults to uwsgi in 2025.2); when undefined
it aborts the keystone service upgrade on every control node.
- enable_ironic_pxe_filter: referenced by the ironic role's service
dict; bites where ironic is enabled (e.g. metalbox).
- nova_database_{address,name,user} and
nova_cell0_database_{address,name,password,shard_id,user}: the nova
cells database globals; the nova_cell0_database_* values reference the
nova_database_* ones and are consumed by the nova role's bootstrap and
map_cell0 tasks.
The change is purely additive and union-safe: these variables are new
in 2025.2, so they are inert on older supported releases (their roles
do not reference them) and defined for 2025.2. nova_cell0_database_password
resolves to the nova_database_password secret from passwords.yml, which
lives outside these defaults.
This is a targeted forward-port; the broader remedy is a full re-sync of
osism/defaults against upstream stable/2025.2.
UpgradeImpact
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Roger Luethi <luethi@osism.tech>
kolla-ansible 2025.2 made ProxySQL the default MariaDB load balancer (enable_proxysql now defaults to enable_mariadb) and removed the internal HAProxy MariaDB frontend from the mariadb role. OSISM's defaults set enable_proxysql unconditionally to "no", a 2025.1-era assumption. On 2025.2 that combination leaves MariaDB with no load-balancer frontend from any source: services.d/mariadb.cfg (HAProxy) renders empty, so there is no :3306 listener on the internal VIP and access to MariaDB through the VIP is refused, failing the mariadb role's own "wait for MariaDB through VIP" readiness gate. Gate enable_proxysql on openstack_version -- off for 2024.1, 2024.2 and 2025.1, on for 2025.2 and later -- mirroring the enable_redis and enable_valkey release gate. mariadb_loadbalancer already derives from enable_proxysql, so the load-balancer selection follows automatically. Note: enable_proxysql=no is no longer a working HAProxy escape hatch on 2025.2, since the internal HAProxy MariaDB frontend was removed upstream; ProxySQL is effectively required for MariaDB HA there (unless enable_external_mariadb_load_balancer is used). UpgradeImpact Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Roger Luethi <luethi@osism.tech>
kolla-ansible 2025.2 switched Horizon to uWSGI by default (horizon_wsgi_provider defaults to "uwsgi"; commit 2b591fb09), the same migration that added keystone_listen_port. The Horizon role now serves uWSGI on horizon_listen_port, and upstream added an "'8080' if enable_haproxy" branch to that variable: behind HAProxy the uWSGI backend must listen on the unprivileged 8080 while HAProxy fronts the privileged 80. OSISM did not pick up that branch. all/001-kolla-defaults.yml carries the pre-uWSGI value (horizon_tls_port if TLS backend else horizon_port, i.e. 80 in the common no-TLS case), and OSISM enables HAProxy by default. On a 2025.2 deploy the uWSGI backend would target the privileged 80 instead of 8080, breaking Horizon behind HAProxy. Override horizon_listen_port in all/099-kolla.yml, release-gated on openstack_version: for 2025.2+ with HAProxy use 8080 (matching upstream), and for 2024.1/2024.2/2025.1 keep the exact previous value so older releases (which still use Apache/mod_wsgi) are unchanged. UpgradeImpact Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Roger Luethi <luethi@osism.tech>
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.
Summary
Three targeted fixes to unblock OpenStack 2025.2 deploy/upgrade.
osism/defaultsmirrors upstream kolla-ansiblegroup_vars/allbut is synced tostable/2025.1, so it diverged from 2025.2; these are the divergences that breaka 2025.2 run. Every change is additive or release-gated, so older supported
releases (2024.1 / 2024.2 / 2025.1) are unaffected.
Changes
Add missing 2025.2 group_vars (
all/001-kolla-defaults.yml), verbatim fromupstream
stable/2025.2:keystone_listen_port— added in the 2025.2 uWSGI migration; when undefinedit aborts the keystone service upgrade on every control node.
enable_ironic_pxe_filter— referenced by the ironic role (bites whereironic is enabled, e.g. metalbox).
nova_database_{address,name,user}andnova_cell0_database_{address,name,password,shard_id,user}.Purely additive and union-safe: these variables are new in 2025.2, so they are
inert on older releases (their roles don't reference them).
Gate
enable_proxysqlby release (all/099-kolla.yml). 2025.2 madeProxySQL the default MariaDB load balancer and removed the internal HAProxy
MariaDB frontend from the mariadb role. OSISM's unconditional
enable_proxysql: "no"then leaves MariaDB with no LB frontend on 2025.2(
VIP:3306refused). Now on for 2025.2+, off for ≤2025.1 — mirroring theexisting
enable_redis/enable_valkeygate.mariadb_loadbalanceralreadyderives from
enable_proxysql, so the LB selection follows.Fix horizon uWSGI listen port (
all/099-kolla.yml). 2025.2 switchedHorizon to uWSGI by default (the same migration as keystone). Behind HAProxy
the uWSGI backend must listen on the unprivileged
8080, not the privileged80; upstream added an'8080' if enable_haproxybranch that OSISM lacked.Release-gated so 2024.x/2025.1 (still Apache) keep the previous value exactly.
Testing
yamllintclean w.r.t. these changes; all transitive variablereferences resolve.
keystone_listen_portandenable_proxysqlfailures were reproduced onlive
10.1.0 → 2025.2upgrades.horizon_listen_portis confirmed at the rolelevel (uWSGI is the 2025.2 default; the port split is required behind HAProxy)
but not yet exercised end-to-end — hence draft, pending a
2025.2upgradeCI run.
Out of scope / follow-ups
osism/defaultsre-sync against upstream 2025.2 — relocateupstream-dropped vars (venus / redis / ironic_inspector / …) into a
# Backward compatibility for 2025.1section.nova_cell0_database_passwordresolves to thenova_database_passwordsecret (
passwords.yml), which must be present on upgrades — separatesecrets-backfill concern.
🤖 Generated with Claude Code