[bitnami/redis] Removes master/slave when using sentinel #3658
Conversation
rafariossaa
force-pushed
the
working_redis_fix
branch
from
175532f to
d17302e
Compare
| runAsUser: {{ .Values.securityContext.runAsUser }} | ||
| {{- end }} | ||
| command: | ||
| - /bin/bash |
There was a problem hiding this comment.
This script is long, maybe it is more maintainable if we move it to a configmap
There was a problem hiding this comment.
I a future review of redis I would like to move the logic to the container scripts where I think it suits best.
What do you think ?
There was a problem hiding this comment.
In order to keep it cleaner, I moved the command shell scripts of all the statefulsets to a new configMap
rafariossaa
force-pushed
the
working_redis_fix
branch
from
7774046 to
c9888d6
Compare
|
This could potentially solve our problem we are having with redis all the time. |
|
I have added some instructions on how to make a backup and restore. |
|
FYI, if you were doing a "single-instance" Redis ( I suppose our approach wasn't supported and I have already moved to |
|
@Klohto same here. I was able to use a single master in dev env but now this PR broke that. I don't think it's fully tested. :( |
|
Thanks for reporting. If a single-instance Redis used to work before, it should still be supported. Let's continue the discussion on #3707. |
Description of the change
This deploy a new statefulset used only when enabling sentinel. This will allow the clients to connect when a slave is promoted.
Benefits
Master/slave statefulsets division is not usable when using sentinels because you can't ensure that the master node is the one in the master statefulset.
Possible drawbacks
Applicable issues
Additional information
Checklist
Chart.yamlaccording to semver.[bitnami/chart])values-production.yamlapart fromvalues.yaml, ensure that you implement the changes in both files