When scaling Foreman, a cache store is needed to ensure that multiple application instances reference the same set of cached data (e.g. user session). Today, as I understand it, this is mostly handled through including the foreman_memache plugin to configure and use a memcached server. This leads me to bring the following design questions up:
Merge foreman_memache to core
Should we deprecate foreman_memcache and move it’s simple functionality directly into Foreman core? This plugin is stupid simple and seems like overhead that’s unneeded for a core platform concept.
Preferred Cache Store Backend
If we go with bringing this functionality into core, we can open this up to using other cache stores such as Redis. This means the user can control their own destiny here. However, my question is what should be our preferred backend. The Pulp project for version 3 has switched their async task engine to RQ which by default uses Redis. Aligning on that would have benefits for content users. And while I think choice can be good for users, being opinionated has a lot of value for deployments, testing and developer environments. (Plus I’d like to centralize on one for container based deployments by default)