The problem/use-case that the feature addresses

As a newcomers to Sentinel, we relied on the Bitnami helm chart. That chart relies on Kubernetes service links, which are disabled by policy in our cluster.

The chart sets up a Sentinel config with monitor $(redis-cli -h $SENTINEL_SERVICE -p $SENTINEL_SERVICE_LINK_PORT sentinel get-master-addr-by-name), and if the query fails it assumes that it's the first node, and therefore should use its own IP as the master to monitor.

In the absence of service links, the query command becomes redis-cli -h a.real.host -p sentinel get-master-addr-by-name and fails as malformed. Then all the nodes come up with a configuration of monitor mymaster my.pod.id - as a result, they each report a different result for get-master-addr-by-name and the cluster fails, but without any indication in the logs of what the problem might be.

Description of the feature

The Sentinels in this case seem like they have enough information to tell that their configuration is wrong - the Redis node they're monitoring reports its own role as slave, the replica graph they have shows that there's a different master, etc. Two of the three Sentinels in our test cluster showed the master flags as master,s_down for an extended period.

As a bare minimum, the Sentinels should shut down with an error about being misconfigured ("master host disagreement with S1!" or something).

Given that, after a failover, the Sentinels would form a quorum on the new master, and record their new master in their config, maybe in the case that the Sentinels are configured in this way, they could agree automatically on a master. In which case a starting config of "your own IP" would be a reasonable and robust approach to setting up Sentinel Redis in modern environments where we don't want to a priori designate a master Redis.

Alternatives you've considered

"git gud, scrub" - this issue arises in part because we're new to Sentinel, and relied on a chart that made assumptions about the configuration of the cluster. (Our use case includes many K8s Services, and as a result enabling service links makes Bash effectively unusable.) As we gain experience, we'd be unlikely to make this error again, but it surely lies in wait for future novices.

Additional information

https://github.com/bitnami/charts/blob/main/bitnami/redis/templates/scripts-configmap.yaml#L327