There have been other threads that include discussion of Redis as part of their implementation. The goal of this RFC is to bring Redis to the forefront and discuss it from the perspective of it’s use in the ecosystem for all use cases.
There are a number of immediate use cases bringing Redis into our ecosystem: Dynflow worker extraction, and Pulp 3 tasking system. There are some discussed use cases for Redis: fact caching, and session caching. The first of these changes will be landing in 1.25 with Dynflow and Pulp 3 both using Redis for their tasking use case.
The following is a recap of where some inter-project discussions landed on how we should deploy Redis within the ecosystem and through the installer:
A single instance tuned for persistent storage serving Dynflow and Pulp 3
Dynflow will use database ‘/0’
Pulp 3 will use database ‘/1’
For the caching use cases, a separate Redis instance tuned for caching will be used
Redis is all about memory
If you start swapping, you will need to add more memory or consider an external Redis but balance this with latency
I think that Foreman cache already uses /0 in the docker compose, and that dynflow is using /1 (at least here) and it would be great if we could control it via ENV variables like in foreman core? (so its easy to use with containers?)
Can we achieve predictability with the ENV variables? Also, based on our findings, Foreman cache should use ‘/0’ in a Redis designated for caching. Meanwhile Dynflow should be using a separate Redis instance designed for persistent storage and use it’s ‘/0’. Sounds like the container setup needs updating to depoy two Redis instances to reflect this.
Is the goal only to bring persistent Redis onboard or both? I would like to see also caching Redis to be deployed by default from now on which I believe is not deployed by default yet.
