Add Valkey support via new valkey role - #374
Closed
Amunagala-itential wants to merge 5 commits into
Closed
Amunagala-itential wants to merge 5 commits into
Amunagala-itential wants to merge 5 commits into
Conversation
Adds roles/valkey as a Remi-free, non-source-compiled alternative to roles/redis, installed exclusively via the native EL9 AppStream package. EL8 is explicitly unsupported and fails validate-vars with a clear error rather than falling back to EPEL8 or a source build. Wires in playbooks/valkey.yml, verify_valkey.yml, certify_valkey.yml, and download_packages_valkey.yml alongside the existing Redis playbooks in platform_site.yml, verify.yml, certify.yml, and download_packages_platform_site.yml, plus adds valkey/valkey_secondary to os.yml's host list. Also adds example_inventories/valkey and docs/valkey_guide.md. Verified against all 4 reference architectures (AIO, Minimal, HA2, ASA) in a live AWS lab: clean verify_valkey.yml/certify_valkey.yml runs on every host, live Sentinel failover tested on both HA2 (colocated sentinels) and ASA (dedicated sentinels) with automatic promotion, replica re-pointing, and old-master rejoin-as-replica, and confirmed Itential Platform connects successfully in both single-node and Sentinel-fronted modes.
Every other role carries an empty README.md alongside its CLAUDE.md; roles/valkey was missing it.
The playbook inventory, roles summary, TLS overview, and docs index tables documented Redis but were never updated when Valkey was added, so Valkey was undiscoverable from the collection's own reference doc.
Mirrors every Redis section with a Valkey equivalent: overview bullet, HA2/ASA architecture notes, required-repositories table (Valkey needs none beyond the base OS's own AppStream repo), ports/firewall table, certificates table, a Valkey Accounts table, verify/certify example commands, a systemctl status example, the Component Guides link, and an Appendix A "Highly Available Valkey" section. Root README.md had no Valkey mentions at all despite the role being fully wired in.
Amunagala-itential
requested review from
Madias2222,
Nick-Andreano and
kvelarde-itential
September 14, 2026 14:12
kvelarde-itential
requested changes
Sep 14, 2026
| gather_facts: true | ||
| become: true | ||
| tasks: | ||
| - name: Verify Valkey Installation # noqa run-once |
Collaborator
There was a problem hiding this comment.
I think the # noqa run-once can be removed here since run-once is not on the task.
| gather_facts: true | ||
| become: true | ||
| tasks: | ||
| - name: Verify Sentinel Installation # noqa run-once |
Collaborator
There was a problem hiding this comment.
I think the # noqa run-once can be removed here since run-once is not on the task.
| # The AppStream package creates /etc/valkey, /var/lib/valkey, /var/log/valkey and | ||
| # /usr/bin/valkey-server itself (with correct ownership and SELinux file contexts already | ||
| # applied by the base OS's selinux-policy), so unlike roles/redis (which also supports a | ||
| # from-source install with non-default paths), there is no directory-creation step here. |
Collaborator
There was a problem hiding this comment.
Does the valkey RPM support relocate? If so, we may still have to run the SELinux stuff.
If it doesn't support relocate, then we will have to document that limitation. Some customers require installations in "non-standard" locations.
Comment on lines
+4
to
+7
| - name: Validate distribution major version | ||
| ansible.builtin.assert: | ||
| that: ansible_distribution_major_version != "7" | ||
| msg: Download not supported for EL 7 |
Collaborator
There was a problem hiding this comment.
I think we can remove this task.
Comment on lines
+51
to
+60
| - name: Check for valid OS for Valkey installation | ||
| ansible.builtin.assert: | ||
| that: | ||
| - ansible_os_family == 'RedHat' | ||
| - ansible_distribution_major_version == '9' | ||
| fail_msg: >- | ||
| Deployer does not support installing Valkey on | ||
| {{ ansible_distribution }} {{ ansible_distribution_major_version | default('') }}. | ||
| Valkey is only supported on RHEL/Rocky/AlmaLinux 9, installed via the native | ||
| AppStream module. Use the redis role instead on EL8 or other platforms. |
Collaborator
There was a problem hiding this comment.
Is Valkey supported on AL2023?
Comment on lines
+72
to
+75
| ## Design Decisions (PE-1948) | ||
|
|
||
| These are deliberate departures from a 1:1 mirror of `roles/redis`, decided during scoping — | ||
| see the PE-1948 Jira comment thread for the full research trail: |
Collaborator
There was a problem hiding this comment.
Remove references to PE-1948.
| | Redis | <https://dl.fedoraproject.org> | TCP | EPEL YUM RPMs<br>When installing Redis from the Remi repository | | ||
| | Redis | <https://github.com> | TCP | Redis source packages <br>When installing Redis from source | | ||
| | Redis | <https://codeload.github.com> | TCP | Redis source packages<br>When installing Redis from source | | ||
| | Valkey | n/a | n/a | No additional public repository required — Valkey installs via the native EL9 AppStream package, already part of the base OS's own repository set. | |
Collaborator
There was a problem hiding this comment.
We still need to document the repo URL even though it is the standard AppStream.
- Remove dead "# noqa run-once" comments in verify_valkey.yml (no run_once on either task) - Remove the redundant EL7 check in validate-vars-offline.yml; fully subsumed by validate-vars.yml's stricter OS assert, which always runs first - Add Amazon Linux 2023 support alongside EL9: AL2023 ships valkey natively via its own core repo (confirmed via AWS's ALAS advisories). Updates validate-vars.yml's OS assert, platform-release-6.yml's package map, and every "EL9 only" doc mention across CLAUDE.md, README.md, and docs/valkey_guide.md - Document that Valkey install paths are not customizable: the RPM has no Prefix: tag and is not relocatable, unlike a from-source Redis install. Customers needing non-standard paths must use roles/redis - Populate valkey_required_repositories with a real, checkable URL (Rocky/AlmaLinux AppStream mirror) instead of an empty list, and update README's Required Public Repositories table to match, noting that RHEL/AL2023 resolve their package source differently and aren't covered by this specific check - Remove "(PE-1948)" ticket reference from roles/valkey/CLAUDE.md's Design Decisions heading
Contributor
Author
|
Addressed in ff3891e:
|
Contributor
Author
|
Closing in favor of the standalone itential.valkey collection: https://github.com/itential/itential.valkey (PR: itential/itential.valkey#2). Valkey support will be developed there and merged into itential.deployer directly once roles/redis is retired, rather than living here in the meantime. |
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.
Body:
Summary
Adds
roles/valkeyas a Remi-free, non-source-compiled alternative toroles/redis, per the scoping/decision thread onPE-1948:
(
dnf install valkey) — no Remi, no source compile, ever.valkey_master/valkey_replica/valkey_sentinelon EL8 failsvalidate-vars.ymlimmediately with a clear error, rather than silently falling back to
EPEL8 or attempting a source build.
fedora-selinux/selinux-policy'sredis.fc: standard Valkey paths(
/usr/bin/valkey-server,/etc/valkey,/var/lib/valkey,/var/log/valkey) are already file-context-equivalenced onto theexisting
redis_exec_t/redis_conf_t/redis_var_lib_t/redis_log_ttypes by the base OS policy — no custom types or.temodule needed.
playbooks/valkey.yml,verify_valkey.yml,certify_valkey.yml,and
download_packages_valkey.ymlin alongside the existing Redisplaybooks in
platform_site.yml,verify.yml,certify.yml, anddownload_packages_platform_site.yml(unconditional parallel imports —a play with zero matching hosts simply skips, so no branching logic
is needed at the root-playbook level for engine selection).
valkey/valkey_secondarytoos.yml's host list.example_inventories/valkey/anddocs/valkey_guide.md.CLAUDE.mdandREADME.mdso Valkey is discoverablealongside every existing Redis reference (playbook inventory, roles
summary, TLS table, ports/firewall table, certificates table, a
Valkey Accounts table, verify/certify examples, HA appendix).
"Dual support" concretely means: operator selects Redis or Valkey
per host group, with Valkey gated to EL9 only. Redis remains the only
option on EL8.
Test plan
All tested live in a 4-architecture AWS lab deployment (AIO, Minimal,
HA2, ASA) on Rocky 9.8:
ansible-lint roles/valkeyclean at parity withroles/redis(warnings only, 0 failures)
verify_valkey.ymlandcertify_valkey.ymlrun clean(
failed=0) on every host across all 4 architectureshistory, not just recent)
INFO replicationroles, online state, low lag)
sentinels) and ASA (dedicated sentinels across 3 DCs):
automatic promotion (~9-13s), automatic replica re-pointing,
data continuity across the failover, automatic rejoin-as-replica
when the old master returns — no manual intervention in either
case
(AIO) and Sentinel-fronted (HA2) modes, including live
confirmation that Platform's own
ioredisclient survived theHA2 failover test automatically (brief ~2s reconnect blip,
self-healed, zero further errors)