sentinel.conf currently mixes both static and runtime configuration that makes it hard to mange this file with some configuration management tool (e.g. Chef) without causing a restart in Sentinel (e.g. https://github.com/bloomberg/redis-cookbook/issues/18). For example, if we change bind or port, we do want to restart Sentinel. However, if Sentinel changes sentinel config-epoch or sentinel known-slave, then Chef might come along, blow away those changes, and restart Sentinel. As mentioned in https://github.com/brianbianco/redisio:
Redis-sentinel will write configuration and state data back into its configuration file. This creates obvious problems when that config is managed by chef. By default, this cookbook will create the config file once, and then leave a breadcrumb that will guard against the file from being updated again.
Proposal: Split the runtime configuration in another file (e.g. sentinel-runtime.conf).
What do you think @antirez?
Comment From: NickCraver
For what it’s worth, we have similar issues with test configs into git. Since Sentinel overwrites our relative paths with absolute paths that vary by where the repo is on each user’s machine, things break. The runtime IDs wouldn’t break things by themselves, but overall it’s the same situation. We have to tell git to ignore all changes (and remember and instruct any new user to do this...otherwise the runtime bits appear in PRs and such). And it doesn’t just affect new users, I did it by accident yesterday.
Can we please allow splitting this out in v5?
Comment From: josephholsten
sous-chefs has recently taken over maintenance of the redisio cookbook: https://github.com/sous-chefs/redisio
We'd be very interested in any solution to this, regardless of whether it's on the chef or Redis side.
Comment From: ffledgling
This issue also comes up when running redis/sentinel in Kubernetes and trying to use config-maps for sentinel.conf, it is difficult to change the config at run-time without restarting the entire cluster because of this. The run-time state and static config really should be separate files and there should be an easy way to ask sentinel to reload/regenerate the state file (via SIGHUP or similar).
Comment From: sreerajkksd
Do we ever expect to tackle this issue ? I have been evaluating redis and sentinel for a firm-wide use-case and has been promising until now. I want to manage my sentinel and redis settings in configurations management (eg: puppet). but sentinel override sentinel.conf so I can only use them for bootstrapping at the moment. That is kind of sad as any configuration change that I'll be doing will require a manual operation on all replicas.
For puppet, I can still make this work by using a puppet helper module for redis https://forge.puppet.com/modules/puppet/redis. But, can we expect anything from the redis dev directly!
Comment From: yossigo
Yes this should definitely be addressed, either as a Sentinel specific issue or as part of a greater configuration story which starts to build up (like #8349, secret configs for #8055, etc.).
Comment From: christopherraa
Any movement on this issue? While the redis-sentinel configuration is technically manageable using automation tools like chef/ansible/puppet it quickly becomes convoluted due to all the parts of the config that has to be ignored or where dynamic values have to be accounted for.