[bitnami/redis] Add support to redis master service with useHostnames false

[fmendez89]

Description of the change

This PR improves the way the current Redis master pod is labeled by Sentinel by introducing synchronization and avoiding race conditions when multiple pods detect a failover. It adds the following changes:

• A shared coordination mechanism using flock to avoid race conditions when labeling pods.
• Skips relabeling if the master hasn't changed, preventing unnecessary updates.
• Adds support for resolving the master pod name by IP when useHostnames is disabled.
• Improves the label management logic by adding isMaster=true to the current master and removing app.kubernetes.io/role.

Benefits

• Avoids concurrent relabeling issues across Sentinel instances.
• Reduces unnecessary pod label updates.
• Ensures correct label assignment in clusters with or without useHostnames.
• Supports both IP and hostname-based master detection.
• Aligns the master labeling logic with the actual Sentinel-detected master.

Possible drawbacks

• Requires that the container has permission to use file locking (should be fine on most Linux distros).
• Relies on a shared writable volume mounted at /etc/shared across pods.

Applicable issues

Fixes #29217

Additional information

This feature is particularly useful when using external services that rely on pod labels (e.g., a Service selector for the master role). It ensures the label is always up-to-date based on Sentinel decisions.

Checklist

• Chart version bumped in Chart.yaml according to semver. This is not necessary when the changes only affect README.md files.
• Variables are documented in the values.yaml and added to the README.md using readme-generator-for-helm
• Title of the pull request follows this pattern [bitnami/redis] Add support to redis master service with useHostnames false
• All commits signed off and in agreement of Developer Certificate of Origin (DCO)

[juan131]

Thanks so much for this great PR! Absolutely brilliant, please check my comments.

[juan131]

Please ensure you merge the latest changes in the origin's main branch in your fork's branch and then, update the PR. Thanks in advance.

[juan131]

Please split this in 2 lines:

Suggested change

	[ -f /etc/shared/previous ] && previous_master=$(< /etc/shared/previous) || previous_master=""
	previous_master=""
	[ -f /etc/shared/previous ] && previous_master=$(< /etc/shared/previous)

[fmendez89]

sure, it's better that way

[juan131]

Is the 1st condition redundant?

Suggested change

	if [ -n "$previous_master" ] && [ "$current_master" = "$previous_master" ]; then
	if [ "$current_master" = "$previous_master" ]; then

[fmendez89]

yes, good catch

[juan131]

In the previous echo you already displayed the variable value:

Suggested change

	echo "Master ($current_master = $previous_master) has not changed, skipping label update and cleaning state"
	echo "Master has not changed, skipping label update and cleaning state"

[fmendez89]

Ok, removing it

[github-actions]

This Pull Request has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thank you for your contribution.

[github-actions]

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Pull Request. Do not hesitate to reopen it later if necessary.

[fmendez89]

Hi @juan131, how can I reopen de PR to push the changes?

[carrodher]

Thanks for your contribution! Could you please bump the chart version in the Chart.yaml? This is necessary to test the changes and cut a new release. Probably it was missing after the latest rebase.