Why am I writing this?
I was listening to Madelyn Olson’s podcast, one of the core maintainers of Valkey, and she mentioned that she’d love to hear more user stories about Valkey. This post is more about the surrounding ecosystem than Valkey itself, but I thought a story about the shift from user to contributor within the ecosystem would also be interesting to share. So here we go …
In my head, open source projects were those big projects run by expert developers with years and years of experience. I never thought I’d be able to contribute anything there, let alone anytime soon.
Before diving in, a quick introduction:
I’m Tim, 29, and I work at a company called ipt in Switzerland. I currently work on a private cloud project, where we offer several services on a Red Hat OpenShift platform — one of which was based on Redis. We provided it in different configurations, including high availability. Then Redis changed its license, and we had to look for an alternative.
“Oh, there’s an open source fork of Redis called Valkey — let’s just switch to that!”
Little did we know what that would actually involve.
After taking a proper look at the Valkey Helm chart and operator, including their open issues, we realized we couldn’t use the solutions as they stood yet. We’d previously used Bitnami’s Redis charts, which gave us a lot of customizability with Go templating and Valkey wasn’t quite there yet. The Helm chart didn’t offer any working high availability configuration. The operator was still in version 0.1.0 and not ready for production use.
My team and I wanted to start shifting the focus from building workarounds downstream to fix issues upstream. Downstream workarounds are often the fastest fix, but you’ll pay for them later on. Every lifecycle means checking whether your workaround still holds or you need to adapt it. After some time you end up with a huge overhead. In our case it wasn’t even the fastest option.
This was the first spark of motivation for some contribution.
In March, my colleagues and I attended the KubeCon conference in Amsterdam. Fortunately, there were two talks held about Valkey. After the session, I talked to Sarthak Aggarwal and Madelyn Olson, core maintainers of Valkey, about contributing, and they encouraged me to join. Back home, I talked to some colleagues at my company, and ipt offered me a program which allows me to contribute 20% of my working hours into an open-source project of my choice.
How to decide on a project?
I wanted to join a project where I already had at least some experience. On both the Helm chart and the operator were some open GitHub issues asking for support.
Since my operator knowledge was limited, I thought this would be a good chance to improve it.
How to start?
On GitHub, it’s common to label easy issues as “good first issue” which are perfect for newcomers to a project. If there aren’t any, just ask the community on either Slack or GitHub.
I was able to find an e2e (End-to-End) test issue related to permission management with ACL. That turned out to be a great starting point. Since I already had some ACL (Access Control List for user management) knowledge, I could quickly get a handle on the testing structure and the operator itself.
Be prepared that you might start with some minor improvements.
All about community
The pace feels a bit different compared to the main project I’m working on. Some maintainers put in a lot of work, while contributors like me only work on it occasionally. A good first step is to check out how the community operates — do they have a Slack channel? Do they meet weekly?
Just be a bit more patient than you might be used to on other non open-source projects.
How AI supports me
I’ve also noticed it takes me much longer to get up to speed on the project, since I’m only working on it about 20% of the time. This is where an agent can help. It can hold a big part of the context of the project for you, so you don’t miss any pitfalls.
There are also AI bots set up on the GitHub repository for reviews, which is really handy since you don’t have to wait long for initial feedback.
What I’ve experienced is that it’s still essential to understand the project and the functionality you’re implementing, otherwise you can’t ask the right questions or properly challenge the suggestions an AI gives you.
How it goes
I’m currently waiting for my fourth PR to get merged. What I didn’t expect is how much one thing leads to the next: working on that first ACL test surfaced other gaps, I opened issues for them, and those became the following tickets. You don’t really run out of work once you start looking.
One PR, #392, added an e2e test for the operator’s own permissions.
The operator doesn’t connect to Valkey as a superuser. It uses a dedicated system user called _operator, whose permissions are defined by an ACL written by hand in the controller code. The problem is that nothing checks that manually maintained list against reality. If someone adds a new command somewhere in the reconciliation logic and forgets to extend the ACL, everything compiles, the unit tests pass, and the operator fails with a permission error in production instead.
So rather than writing a test that checks the commands maintained in a list, I wrote one that discovers them.
The first part is a small package that parses the operator’s own source with Go’s go/ast and collects every Valkey command the code can issue. valkey-go exposes commands as builder methods, so CLUSTER SET-CONFIG-EPOCH shows up in the code as ClusterSetConfigEpoch. Instead of hardcoding the mapping the scanner parses valkey-go’s own generated builders and reads the command tokens out of them, so the mapping updates itself.
The second part wires this into the e2e suite: for every command the scanner finds, the test runs ACL DRYRUN _operator <command> against a live cluster and fails if any of them is denied.
ACL DRYRUN wants a syntactically valid command, so sending a bare CLUSTER SET-CONFIG-EPOCH leads to a “wrong number of arguments” error. The fix was to ask the server for each command’s arity via COMMAND INFO and pad with placeholder arguments before running the dry run e.g. ACL DRYRUN _operator CLUSTER SET-CONFIG-EPOCH x.
I also added a small CLI, so anyone updating the ACL by hand can run go run ./hack/aclscan and see the current list.
What’s next?
Since I wanted to extend my scope beyond testing, I asked Joe Heyburn, one of the operator maintainers, what would be useful to pick up next. Maintainers usually have a mental backlog of things they’d love someone to take. As the next issue I would like to have a look at #262 which includes changes on the CRD.
I’m looking forward to gaining more experience and contribute more in the future.
Thanks to the Valkey community for making it easy to get started and to ipt for the support!