[bitnami/redis] Redis helm chart checksum/secret recalculation

[farioas]

Name and Version

bitnami/redis 20.6.3

What architecture are you using?

amd64

What steps will reproduce the bug?

1. Start with an empty deployment environment and the following values:

architecture: standalone
auth:
  enabled: true
master:
  resources:
    requests:
      memory: "100Mi"
      cpu: "100m"
    limits:
      memory: "100Mi"
  persistence:
    enabled: true
tls:
  enabled: true
  autoGenerated: true

2. Run the following command to deploy Redis:

helm template --dry-run=server my-redis bitnami/redis --values values.yaml | kubectl apply -f -

Redis is successfully deployed.

3. Run the following command to check for diffs:

helm template --dry-run=server my-redis bitnami/redis --values values.yaml | kubectl diff -f -

Observed Diff:

- checksum/secret: dd4b1164e04884db75f070df18ce8f45027481216c93a89a3f0209f41acedea2
+ checksum/secret: ce23a18a82b6efbd5aa7104b1e0c7d8359ddce635b61678ee723a01b60371652

4. Apply the changes:

helm template --dry-run=server my-redis bitnami/redis --values values.yaml | kubectl apply -f -

5. Run the diff again:
   No Diff: The checksum remains stable after this step.

Are you using any custom parameters or values?

Yes, it was mentioned above: custom values and --dry-run=server to guarantee access for secrets.

What is the expected behavior?

The checksum/secret annotation should not change between runs unless there is an actual change in the secret values. This would prevent unnecessary rolling updates and stabilize Redis deployments, particularly for short-lived environments.

What do you see instead?

When using Redis with Bitnami Helm charts and deploying via an idempotent templating approach (e.g., ArgoCD), the checksum/secret annotation in Redis StatefulSet gets updated on subsequent runs of helm template. This causes the StatefulSet to trigger rolling updates unnecessarily, as the secret checksum changes after the first run.

This behavior impacts temporary or short-lived environments (e.g., feature branches), where the secrets do not stabilize before the environment is destroyed.

Additional information

This behavior appears to be linked to ArgoCD’s idempotent reconciliation strategy, where it regenerates templates on each sync.
Long-running deployment are not affected, as the checksum stabilizes over time.
Related issues in Bitnami Charts:
#29406
#24870

This issue is particularly disruptive in CI/CD pipelines for feature branch environments where consistency is critical for testing.

[carrodher]

Thank you for bringing this issue to our attention. We appreciate your involvement! If you're interested in contributing a solution, we welcome you to create a pull request. The Bitnami team is excited to review your submission and offer feedback. You can find the contributing guidelines here.

Your contribution will greatly benefit the community. Feel free to reach out if you have any questions or need assistance.

[farioas]

If you can give me a hint on which way to work, I think I can fix it.
So far I have no idea why the SHA of the secret.yaml file is changing between initial install and 2nd install.
include "common.secrets.passwords.manage" this function is used in many charts, so it must be a known issue.

[carrodher]

Note that Helm does not automatically remove PVs/PVCs when uninstalling Helm charts. If you reinstall the chart using the same name and/or namespace, there may be a conflict between the password stored in the PV from the initial deployment and the new random password generated during subsequent installations.

To avoid this conflict, you can:

• Pass the original password as a parameter during the installation.
• Use a different name or namespace for the new deployment.
• Manually remove the PVs/PVCs from the previous deployment.

[farioas]

I didn't say I did the uninstall or mentioned pvc's.

All what I did is just run this command twice:

helm template --dry-run=server my-redis bitnami/redis --values values.yaml | kubectl apply -f -

[farioas]

there may be a conflict between the password stored in the PV from the initial deployment and the new random password generated during subsequent installations.

This is also not true. The secret is not changed, only checksum/secret for sts.

[javsalgar]

Hi,

Could you try setting the password in the values above? Just to confirm that the issue also happens.

[farioas]

Hi,

Could you try setting the password in the values above? Just to confirm that the issue also happens.

I can verify that the issue doesn't reproduce with auth.password set, so I'm currently using this as a workaround.