kolla: switch redis to valkey for 2025.2+ (release-conditional)#292
Merged
Conversation
Since release 9.1.0 a single osism/defaults tag is shared across the whole OpenStack-release menu (2024.1/2024.2/2025.1/2025.2 all pin the same defaults_version; base.yml no longer fixes openstack_version). valkey exists upstream only at 2025.2 -- stable/2025.1 is redis-only (no valkey role / no playbook-valkey.yml). A flat enable_valkey/disable enable_redis flip would therefore break every 2025.1/2024.x deploy sharing the tag. Gate both flags on openstack_version instead, mirroring the existing release-conditional idiom already used in defaults (mariadb_image, prometheus_server_image): redis stays enabled for 2024.1/2024.2/2025.1, valkey is enabled for 2025.2 and everything newer (incl. master). This supersedes the earlier unconditional enable_valkey flip. The five coordination/incoming backends that consume these flags are repointed to valkey in a follow-up commit. UpgradeImpact Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Roger Luethi <luethi@osism.tech>
Upstream kolla-ansible replaced redis with valkey at stable/2025.2, but OSISM's defaults still override the coordination/incoming backends back to the redis form, so nothing consumes valkey even where it is enabled. Prefer valkey when enable_valkey is set, keeping the existing redis and etcd fallbacks so older releases (which stay redis-enabled, see the enable-flag gating commit) resolve exactly as before. Updated: - masakari_coordination_backend - gnocchi_incoming_storage - cinder_coordination_backend - designate_coordination_backend - ironic_coordination_backend Also route osprofiler_backend_connection_string to whichever store is enabled: with osprofiler_backend in [redis, valkey] it follows enable_valkey/enable_redis, so on 2025.2 it points at valkey instead of a redis service that no longer exists. The default backend stays elasticsearch, so this path is dormant unless an operator opts in. Resolution per release: 2024.1/2024.2/2025.1 -> redis; 2025.2 and newer -> valkey. Comments updated to list valkey as a valid option. UpgradeImpact Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Roger Luethi <luethi@osism.tech>
This was referenced Jun 29, 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
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.
Part of the OSISM-wide redis → valkey migration (upstream kolla-ansible
replaced redis with valkey at
stable/2025.2).Makes the OSISM defaults switch-over release-conditional:
enable_redis/enable_valkeygate onopenstack_version— redis for2024.1/2024.2/2025.1, valkey for 2025.2 and newer.
designate, ironic) plus
osprofilerprefer valkey when enabled, keeping theredis/etcd fallbacks so older releases resolve exactly as before.
It must be release-conditional because one
defaults_versiontag is consumed bymultiple OpenStack releases at once, and valkey exists upstream only at 2025.2.
Draft: defaults and the consumer-script changes must land together, and the
release
defaults_versionpin bump is the cut-over gate — held as draft untilthat coordinated landing.
Part of the redis → valkey migration (all must land together, gated on the
release
defaults_versionpin bump):🤖 Generated with Claude Code