fix: delete redis from bitnami and provide own templates

[omrozowicz-splunk]

Description

This PR:

1. Removes bitnami redis dependency
2. Upgrade redis version to the newest
3. Add redis authentication — both plain text and secret

Fixes # (issue)

Type of change

Please delete options that are not relevant.

• Dependency update
• Refactor/improvement
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

TBD

Checklist

• My commit message is conventional
• I have run pre-commit on all files before creating the PR
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• I have checked my code and corrected any misspellings

[Kawron]

"or" with single value

[omrozowicz-splunk]

fixed

[Kawron]

Do we need to do this? We shouldn't have to save the password as it is already done in the config map.

And if someone will change the config map, the /etc/redis/redis.conf file will be updated but not the /tmp/redis.conf so for changes to apply the redis container has to be restarted.

So maybe we should stick to the original file, or add to the documentation that the redis has to be restared each time someone changes the config map?

[omrozowicz-splunk]

I think in every case when we use secrets this is the scenario that you have to recreate pods in order for them to mount a new secret (same with configmap). I think it is a good idea to add it to the documentation.

[mattk42]

The restart requirement can be avoided if in the statefulset's pod tempate we add an annotation that includes a checksum of the configmap's values with something like below:

checksum/config: {{ include (print $.Template.BasePath "templates/redis/redis-config.yaml") . | sha256sum }}

[omrozowicz-splunk]

hello @mattk42, thanks for the comment! 😄 I updated the template and tested — it works fine.
But in this case it'd be more beneficial to have such annotation for secrets. The only thing is that then we'd need to include such annotation on almost every pod (as all of them connect to the redis and have redis secret being mounted to it in order to calculate the connection string). Does it make sense? Is this how it should be done? The alternative way is to document that user has to recreate pods after changing secret's value.

Also, it would be difficult to calculate it as we can either have secret created from the /redis-redis-secret.yaml or the secret passed by the redis.auth.existingSecret

[mattk42]

Yeah, that would be challenging and would add to the complexity of the chart as a whole. Personally I do really like automating the restarts, but it may not be worth the complexity in this case especially if it does not happen often.