-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Investigate Offering OSS alternatives to Redis in Argo CD installations #17970
Comments
Worth adding that the result may not be replacing redis at all. We're not required to by the license. |
Sharing the discussion where it was brought up |
Hey, I'm one of the maintainers of Valkey. I just wanted to drop by to add some more context. Feel free to @me with questions if you have any.
I want to highlight that most of the top contributors are no longer working on Redis Community Edition, and moved to Valkey. Yes there will be support, but we already have fixes in our 7.2.5 that weren't present in their latest 7.2 release. Also it seems you are on 7.0, which will have its support dropped sooner (Unless they changed their support policy, it'll be in 2025).
I think this is the right framing, don't rush the decision. My guidance so far has been to wait until you would normally do an upgrade and then treat the move to Valkey as a minor version bump. We are fully compatible, so it's easy to test on, but take your time. |
Hello, github.com/alicebob/miniredis/v2 v2.33.0 Will these packages work seamlessly with Valkey? Also, I observed that Valkey has a separate go client - https://github.com/valkey-io/valkey-go?tab=readme-ov-file#features |
As of today, the same go client that works with Redis will also work with Valkey. Both Redis and Valkey use the same RESP protocol, so as long as you aren't using any of the new features it should be a drop in replacement. I quickly checked the packages, and they should all work except miniredis. Miniredis is a "fake" redis used for testing, so it should be fine to use. |
Is there any progress on this? The old version of redis currently used by argocd's kustomizations is starting to get flagged by update tools as significantly out of date. |
ValKey is 8.0 is GA as of last month and a patch has been dropped in the past week (8.0.1). It should be fully compatible with redis 7.X.X. I think switching to a compatible alternative like ValKey sooner will help keep it a low risk change versus doing it later. |
@todaywasawesome is this something a corporate sponsor like Akuity or Codefresh would handle on it's own time/schedule, or is there anything we as OSS/individual contributors can do to help push this forward? |
afaik there's no reason we can't start making changes upstream. I know the redis-ha setup is complex, and I'm not sure if we can take advantage of that with an alternative tool or if we will have to rebuild or find an alternative for it. |
No, I think anyone can contribute. First, I'd like to give an option for people to opt into Valley or even just docs on how to replace. Then I think adding some tests to start offering support makes sense. Afaik, people can keep using Redis with its license change and I know we have users using the enterprise version with Argo CD. |
My team has opted into replacing Redis 7.2.x with Valkey 7.2.x (although we're not running in HA). So far it is definitely a drop-in replacement, haven't found any issues with it. I assume the HA setup would be a similar experience, but someone else has to verify that. I'd not jump onto the 8.x train immediatelly, as right now Valkey 7.2 branch is still getting security patches. The ArgoCD project should make sure that everything is migrated to Valkey 7.2.7, as that's the closest to the redis version referenced by the argocd helm chart today. In the meantime work on a branch on Valkey 8.x adoption for 2.13.0? I don't mind people using Valkey or Redis or whatever as long as it's api-compatible so replacing it is trivial. But the ArgoCD project as a CNCF project should default to an infrastructure component that has a CNCF-compatible license and keeps getting security patches under a CNCF-compatible license. Right now that is not met with the new license of Redis. |
Summary
The Redis License is changing from BSD-3-Clause to RSALv2 and SSPLv1 which are not open source under the OSI definition. We should consider open-source alternatives as a default replacement for Redis.
Motivation
First off, let's recognize @hairmare for bringing the suggestion to switch to ValKey in #17892. There are several reasons we should consider a replacement:
Proposal
There are at least two potential drop-in replacements for Redis that would still maintain compatibility with the Redis API.
Valkey is a CNCF fork of existing Redis BSD-3-Clause meant to be a drop in replacement that will maintain compatibility.
KeyDB is a performance-focused fork with several years of commits. It's primarily based on Redis 6 and does anticipate some impact from the Redis License change.
We should evaluate all potential options, including changing the way we leverage Redis today. We need a spike to review the implications of using these alternatives and measure performance impacts. In the meantime, we should keep in mind:
The text was updated successfully, but these errors were encountered: