The problem/use-case that the feature addresses I think redis.conf should have an option to read configs from a directory (for example: /etc/redis/redis.d).
Description of the feature This option is very useful for deb/rpm package stuff. That means other packages can add their own redis config to this directory to overwrite and change main config. Also it can be use priority by prefix numbering like this:
/etc/redis/redis.d:
/etc/redis/redis.d/10-my-app.conf
/etc/redis/redis.d/20-your-app.conf
Additional information Many applications have this feature and i think it is very useful.
Comment From: iakkus
I am not sure whether such an approach would make sense. Imagine that my-app and your-app have conflicting config values (e.g., port number, persistence, cluster, eviction policies).
Although some parameters may be chosen according to the priorities (maybe there is a common denominator in some parameters?), I don't think priorities would solve all of the above conflicts. For example, if my-app gets to choose the port because it is higher in the list, how would your-app know about the actually used port number?
I think there are several discussions on "one redis instance per app" choice and the ongoing trends towards moving away from "databases inside redis" (e.g., 0, 1, 2, ...). As such, this feature probably would not be applicable.
Comment From: sambo770
My take on this issue is more along the lines of streamlining upgrades (and downgrades) of redis.
Currently, we're experiencing pain in this area because our configuration customizations within redis.conf keep getting clobbered by dpkg. Ideally, as we've done with other packages such as Apache and MySQL, we would benefit from restoring redis.conf to it's default and moving all our customizations to a 99-local.conf file in the .d config directory knowing full well that none of our settings will be touched as we upgrade.
Comment From: oranagra
solved by #8980