Repository navigation
[FEATURE] Make Redis optional when author attribution is disabled #204
Description
the problem
When running in committer-only mode (--author-attribution=false), Redis should not be a required dependency as the watch cursor store already handles a nil store gracefully. Running and maintaining a redis instance is unnecessary work if the performance drawbacks on restarts are unimportant
the solution
- If --redis-addr is empty, skip all Redis wiring entirely
- The operator starts and watches function normally; on restart, each watch replays from scratch instead of resuming from a cursor
- If --author-attribution=true is requested without a Redis address, fail fast with a clear error (attribution requires Redis)
- The readiness gate is skipped when no Redis is configured (already nil-safe)
What do you think @sunib ? This would make running it for us much easier and wouldn't be a big change in the code.
Activity
sunib commentedon Jul 7, 2026
Thanks, good one. Before I add a second wiring path I want to poke at it a bit,
because a couple of things might make the whole burden go away.
For gitops-reverser, Valkey is just a small throwaway cache:
And I'm happy to put this in writing: in gitops-reverser Valkey stays a cache
and nothing more. It never holds the only copy of anything, it never needs
persistence or backups, and I'm not going to grow a durable / long term storage
requirement into it. Git is the source of truth, Valkey is disposable. Lose the
lot and you just cold-replay from the cluster.
That lets me bundle it into the helm chart sized to what you actually run:
The "minimal" row is basically what you're asking for. So the real question is
where the pain sits for you once Valkey is one small no-persistence pod:
mirroring, per-dependency review)?
The other side to weigh: the minimal row cold-replays on every restart and
rolling deploy, so a full relist plus diff of your whole watched set with no
resume cursor. Cheap on a small cluster, less so on a big or busy one. So:
I'm really trying to be open minded btw. But I'm also a bit hesitant because I would like to avoid to many different options.
consooo commentedon Jul 7, 2026
Thanks for the quick answer! Yes, I'm all for keeping options few and simple. The reason I'm asking is precisely because we want to keep the tooling as simple as possible too.
As you said, it's only used for caching. For us, there will probably be only very few special kinds we would like to watch, with maybe 2000 objects in total. Performance is not really a concern. It's okay if it takes a few minutes for a commit to come through if the pod happens to be restarted. And the traffic should also not be too much of a concern as the objects are not that big.
The reason why it would be much easier for us without valkey is simply that it will be yet another pod to manage within the cluster. Security is a real concern so we need to monitor valkey for vulnerabilities, handle patching etc in an air-gapped cluster. If, for instance, there is a huge problem with it and we need to get rid of it, we would lose the reverser too. Or if a security relevant release is not yet supported by reverser.
So in the spirit of minimising risk and maintenance effort, it would be much better if we could run reverser without redis/valkey.
sunib commentedon Jul 8, 2026
I understand: thanks for your quick follow-up. I'll try to implement this by the end of the week.
If you feel up to it you can also create a PR perhaps? It does help the project to have more different contributors.