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