F41 Change Proposal: Replace Redis with Valkey (system-wide)

Project Discussion Change Proposals
,
1

Replace Redis with Valkey

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

Obsolete Redis for Valkey due to Redis’s license change to RASLv2/SSPL.

:link: Owner

:link: Detailed Description

We will replace Redis with Valkey due to the recent licensing changes in Redis, which have rendered it incompatible with Free and Open Source Software (FOSS) principles. This shift in Redis’s licensing can impact Fedora’s commitment to FOSS, potentially limiting users’ freedom to modify and redistribute the software under the same terms. Valkey, a fork of Redis, emerges as a viable alternative because it retains a FOSS-compatible license and has robust community and developmental support. Adopting Valkey allows us to continue offering users a powerful in-memory data structure store without compromising on licensing restrictions.

:link: Feedback

:link: Benefit to Fedora

Redis previously used the BSD license. Redis’s shift to the Server Side Public License (SSPL) that Fedora does not allow poses an issue. Valkey adheres to the original BSD licensing model, thus maintaining full FOSS compatibility. This commitment is bolstered by substantial backing from the Linux Foundation and the migration of many former Redis contributors to Valkey, ensuring a robust development environment and continuity of expertise.

As the package owner of Valkey in Fedora, my interactions with the Valkey upstream project have underscored their strong dedication to working with distributions. The Valkey team is responsive and proactive in discussions, which facilitates effective package management and integration within Fedora. Their commitment to open collaboration significantly benefits Fedora, ensuring that Valkey is not only technically sound, but also aligns with Fedora’s principles and community values.

This shift to Valkey allows Fedora to maintain its leadership in offering powerful FOSS-aligned technologies while supporting a project that values open source integrity and collaboration. This is crucial for keeping Fedora at the forefront of providing robust, community-supported software solutions to its users.

:link: Scope

  • Proposal owners: add a valkey-compat package which will port Redis configurations to Valkey. Valkey 7.2.5 is 100% compatible with Redis. Add “Obsolete: redis” to valkey-compat package. valkey-compat will require valkey. This will allow us to eventually retire the valkey-compat sub-package at some point in the future.

  • Other developers: N/A

  • Release engineering: N/A

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with Community Initiatives: N/A

:link: Upgrade/compatibility impact

When upgrading to Fedora Linux 41, systems with redis installed will be switched to valkey via the valkey-compat package. The change should be mostly transparent to users as the valkey-compat package provides config and data migration for most common configurations. The valkey systemd units will have aliases for redis to ease the migration for users.

:link: How To Test

A COPR is available at jonathanspw/valkey Copr with the “Obsoletes” in place so the migration script can be tested.

:link: User Experience

This is intended to be as invisible to users as possible. If the change proposal is approved the valkey serviced units will be aliased to redis.service to ease the transition.

:link: Dependencies

:link: Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) Do not obsolete Redis with Valkey
  • Contingency deadline: N/A
  • Blocks release? No

:link: Documentation

N/A (not a System Wide Change)

:link: Release Notes

Last edited by @amoloney 2024-04-17T15:41:20Z

1 Like
2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply giving that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

Is this to be done with RPM package scripts, or is it a systemd one-shot, or something else?

I’m torn between “just works” and “user control / least surprise” here.

RPM scripts can be really confusing, fragile — and hard to fix if something surprising goes wrong that breaks further upgrades.

4 Likes
4

The intent is to execute an included bash script. In POC testing it works well.

What is actually required to move from Redis to Valkey is rather simple - copy the config to /etc/valkey/valkey.conf, stop redis (handled by Obsoletes in the compat package containing the scripts), copy the rdb data files into the valkey data dir, then start valkey.

POC script: Tree - rpms/valkey - src.fedoraproject.org

I’m open to suggestions or better ideas if any exist, however.

5

I think this should be fine, but I’d call this package valkey-redis-compat or valkey-compat-redis (depending on how you prefer naming conventions). This is specifically about replacing Redis, not other things.

4 Likes
6

I’m not too picky on the naming and I like this idea too. I’d lean towards the latter name, valkey-compat-redis as I feel it’s more clear but truth be told if someone had a strong argument for the former I could be swayed.

7

I will defer to FESCo and the FPC on any guidelines on the best way to handle this kind of thing. I’m generally in favor of this, just wanted to make sure the issue was raised.

8

I agree we’ll have to get rid of redis in the future, and than such a switch will make a strong statement about our disapproval to redis about this License change.

But I also think this is a bit early (F41)

  • Valkey is very young, and they is no proof it will be best choice

  • Redis 7.2 is still there and maintained (even version 6.2 and 7.0 are maintained), and keeping it have no security issue.

So I’m -1 for F41 and probably +1 for F42

2 Likes
9

I also would likely support a similar proposal for f42, with the caveats listed below.

  • This change proposal potentially breaks multiple existing packages and time will be needed to manage the transition so that Fedora users are not affected. The three redis module packages we ship are directly broken and their migration needs more planning. However, they’re not the only packages impacted. Just in my immediate sphere, all of pcp, grafana, cockpit-pcp, ansible-pcp, grafana-pcp and the linux-system-roles packages are impacted.

  • Making these packages valkey-aware is a prerequisite before this full-redis-replacement proposal proceeds.

  • Move the redis command compatibility symlinks to valkey-compat (or whatever it becomes).

  • Move the Conflicts: line from valkey to valkey-compat (or whatever it becomes) and remove the valkey-devel Conflicts: line, there are no conflicting files there.

  • The redis man page patch that was removed should have s/redis/valkey/g applied and be reinstated in valkey.spec - I’ll open a separate bug for this as Neal mentioned there should be further changes and an upstream PR opened for this.

  • The redis/valkey-doc sub-package that was removed needs to be reinstated, this is used to ensure up-to-date docs are used in the build (see src/commands.def) - I’ll open a separate bug for this.

  • The valkey package should be group maintained with the existing redis package maintainers (if they wish). This is feeling a bit like a hostile takeover currently and that’s really unnecessary.

As shown above, redis/valkey packaging has subtleties and numerous dependent packages need detailed consideration. We are fortunate to have maintainers who have been working on this package for many years - let’s draw on their experience with valkey going forward please.

1 Like
10

The documentation bugs I mentioned above are now:
https://bugzilla.redhat.com/show_bug.cgi?id=2276017
https://bugzilla.redhat.com/show_bug.cgi?id=2276020

I’d like to see these resolved too as part of this proposal as they’re regressions from the redis package being replaced.

11

I think there may be a problem with the way this script handles permissions. I see it does a mv not cp (good thing, these files can be huge) but the permissions are like:

find /var/lib/redis/ | xargs ls -ld

drwxr-x—. 1 redis redis 48 Apr 19 13:20 /var/lib/redis/
-rw-r–r–. 1 redis redis 341451234 Apr 19 13:19 /var/lib/redis/dump.rdb
-rw-r–r–. 1 redis redis 124170240 Apr 19 13:20 /var/lib/redis/temp-2823803.rdb

The script will end up with files owned and writable only by the redis user when moved into the valkey location. This can be fixed by judicious use of chown (as long as the valkey account exists when this script is run), but care also needs to be taken to ensure redis-server is not running, actively writing to the rdb file (script could check that using a redis-cli PING).

12

It’s a very early draft/POC. It needs quite a bit of work and plenty of extra checks before being production ready. Since F41 is 6 months away we have plenty of time to perfect it.

I didn’t want to spend too much time on the scripts yet in case the proposal got vehemently rejected for whatever reason.

13

FWIW, I can’t imagine anyone outright rejecting this approach (perhaps redict folk?) - its on the right track, IMO, and we all know some action must be taken to drop redis in the not-too-distant future.

Let’s just slow it down and take extra care. Data loss can easily be the result of any mistakes we accidentally make here.

14

That’s no problem, it’ll improve with time for sure.

Given this though, and the accidental redis data loss scenario a valkey install can cause (described on fedora-devel), I think we should hold off on the valkey update that is currently in testing for stable Fedora and EPEL (rawhide totally appropriate though).

15

The easier thing to do is to simply disable the compat subpackage until we have it worked out for F41. That’s straightforward enough to do and does not inhibit the progress of getting Valkey to replace Redis in F41.

1 Like
16

This change proposal has now been submitted to FESCo with ticket #3203 for voting.

To find out more, please visit our Changes Policy documentation.

17
18

This change has been accepted by FESCo for Fedora Linux 41. A full list of approved changes to date can be found on the Change Set Page.

To find out more about how our changes policy works, please visit our docs site.

1 Like