Skip to content

role:valkey: implement Valkey as an alternative to Redis #261

@markuslf

Description

@markuslf

Describe the solution you would like

Add a valkey role (and an accompanying repo_valkey role if a dedicated repo
is needed) to install and configure Valkey as a drop-in alternative to Redis.
Decide and document a per-platform default for the key-value store used by LFOps
playbooks.

Why this needs to be addressed

The driver differs per platform, which is exactly why a single Valkey path is
worth having:

  1. RHEL 10: forced. No redis package exists at all; the redis role loses
    its first-party base and falls back to third-party sources (Remi module
    streams or redis.io). Valkey from the AppStream is the only supported,
    module-free path.

  2. Debian / Ubuntu: license- and consistency-driven. Redis stays available,
    but the 2024 relicense and the per-release license churn (BSD -> SSPL ->
    AGPLv3) make a stable, BSD-licensed default attractive. Debian 13 and Ubuntu
    24.04 already ship Valkey, so LFOps can offer it without third-party repos.

  3. One product across the fleet. Without a Valkey role, RHEL 10 hosts drift
    onto a different key-value store (or a third-party Redis) than the Debian /
    RHEL 9 hosts. A Valkey role lets us standardise on one Redis-compatible store
    across all supported platforms, reducing the support matrix.

  4. Security updates and support. Distro-shipped Valkey (AppStream / Debian /
    Ubuntu) gets vendor security backports on the distro cadence; a third-party
    Redis depends on a separate trust anchor and update schedule per host.

  5. Migration cost grows with time. Every host provisioned now without a
    Valkey path is a future migration. The valkey-redis-compat tooling on Ubuntu
    and Valkey's wire compatibility make an early switch cheap; deferring it does
    not.

Facts: RHEL / Rocky (default repos + EPEL, verified 2026-05-24)

EL redis (distro / EPEL) valkey (distro / EPEL)
8 - EPEL 8.0.9
9 AppStream AppStream 8.0.7
10 not shipped AppStream 8.0.7

Since RHEL 10 makes Valkey the default key-value store, LFOps needs a supported
path that does not depend on Redis there.

Facts: Debian / Ubuntu (default repos, verified 2026-05-24)

Distro redis-server valkey-server
Debian 12 (bookworm) 7.0.15 not available
Debian 13 (trixie) 8.0.2 8.1.1
Ubuntu 22.04 (jammy) 6.0.16 not available
Ubuntu 24.04 (noble) 7.0.15 7.2.12 (+ valkey-redis-compat)

Key differences from RHEL:

  • Redis is not dropped. Unlike RHEL 10, Debian and Ubuntu keep redis-server
    in every current release. There is no "no key-value store" gap to fill.
  • Both coexist in the newest releases. Debian 13 and Ubuntu 24.04 ship redis
    and valkey side by side from the default repos, no third-party repo needed.
  • Older suites (Debian 12, Ubuntu 22.04) have redis only; valkey arrived later.
  • Ubuntu 24.04 also ships valkey-redis-compat (conversion script and
    Redis-compat symlinks), which eases a redis-to-valkey migration.

License note (applies to all platforms)

Redis left the OSI-approved open-source path in 2024 (SSPLv1 / RSALv2, starting
with Redis 7.4). Redis 8.0 (2025) re-added AGPLv3 as an option, so Debian 13's
redis 8.0.2 is OSI-open again, while Debian 12 / Ubuntu redis predate the
relicense and are BSD. Valkey (Linux Foundation, BSD) sidesteps this churn
entirely and is the safer long-term default where open-source-only constraints
apply.

The Remi repo problem in this context

Today the redis role can pull an up-to-date Redis from the Remi repo. On
RHEL 10 this is problematic:

  • Remi ships real Redis only as module streams (redis remi-7.2 ..
    remi-8.8, 8.8 is rc1, latest stable 8.6). There is no plain/versioned
    redis package in remi-safe.
  • Remi ships Valkey also only as module streams (valkey remi-8.1,
    remi-9.0, remi-9.1). No plain valkey package in remi / remi-safe.
  • Module streams are deprecated on RHEL 10 (see the linked repo_remi issue).

So on RHEL 10 the only non-module key-value store is valkey from the AppStream
(8.0.7). Remi would only add value for newer Valkey lines (up to 9.1), and only
via the deprecated module mechanism.

Is Remi even needed from RHEL 10 on?

For Valkey: no. The AppStream ships it without modules. Remi would only be needed
for a newer Valkey major than 8.0, at the cost of relying on deprecated module
streams. Proposal: on RHEL 10, source Valkey from the AppStream and keep Remi out
of the key-value-store path. To be decided as part of this issue.

Alternatives considered

  • Stay on Redis via Remi module streams on RHEL 10. Rejected: depends on a
    deprecated mechanism and a non-default product.
  • Redis from the official redis.io repo (repo_redis) on RHEL 10. Possible but
    swims against the distro default and the license situation.

Additional context

Related: #262 (repo_remi / module streams on RHEL 10).

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions