* redis chart: fix wrong propagation of loadBalancerSourceRanges
Signed-off-by: Samuel Linclau <samuel@linclau.fr>
* bump version
Signed-off-by: Samuel Linclau <samuel@linclau.fr>
---------
Signed-off-by: Samuel Linclau <samuel@linclau.fr>
PR #14420 added probes for the metrics container. However, the new
Helm values are only included for the startupProbe, but not for
the livenessProbe and readinessProbe, i.e. those have always k8s
default values.
Signed-off-by: Simon Baatz <gmbnomis@gmail.com>
Signed-off-by: Simon Baatz <gmbnomis@gmail.com>
* [bitnami/redis] Sentinel deployment: Fix Failover at graceful shutdown
Achieving a proper failover at graceful shutdown of the redis master
pod is tricky (see #13021 and #12598 for discussions of different
options).
The currently implemented solution does not work as intended because
of a syntax error (see #13956). After fixing the syntax error, it
turns out that the intended solution does not work, as it issues a
"SENTINEL FAILOVER" as well as a Redis "FAILOVER". These failover
commands are unrelated and were not designed to work
together. Problems are for example:
1. Redis "FAILOVER" and "SENTINEL FAILOVER" may select different new
master nodes.
2. As part of Redis "FAILOVER", the master will wait for lagging
replicas. But while waiting, the replicas may "disappear" because
the sentinel failover procedure is reconfiguring them. This causes
the redis failover procedure to hang until it times out.
In summary, the Redis "FAILOVER" command can't be used in this
context.
Instead, implement the following when the redis master pod shuts down:
1. Issue a "CLIENT PAUSE" command on the Redis master. This will block
all writes. Reads can still happen.
2. Trigger a failover to a different master by issuing a "SENTINEL
FAILOVER" command.
3. The shutdown of the sentinel container is delayed until the
sentinel returns a different master (i.e. the failover has
succeeded from a client's perspective)
Optionally (the default), also delay the shutdown of the redis
container until that point.
The delayed shutdown of the Redis container maximizes the availability
of Redis during the failover (at least for reads). However, as
discussed in
https://github.com/bitnami/charts/pull/13021#issuecomment-1289177976,
it has drawbacks when short timeouts are used by clients and can
therefore be switched off by setting
`sentinel.redisShutdownWaitFailover=false`.
Note: Because of the syntax error in the previous code, its behavior
actually corresponds to the behavior implemented by this commit when
`sentinel.redisShutdownWaitFailover=False`.
Closes#13956
Signed-off-by: Simon Baatz <gmbnomis@gmail.com>
Signed-off-by: Simon Baatz <gmbnomis@gmail.com>
Signed-off-by: Fran Mulero <fmulero@vmware.com>
Co-authored-by: Fran Mulero <fmulero@vmware.com>
As minReadySeconds is a recent addition to Statefulset (graduated to beta
in Kubernetes 1.23), add the field conditionally, i.e. only if the value
is not zero.
Signed-off-by: Simon Baatz <gmbnomis@gmail.com>
Signed-off-by: Simon Baatz <gmbnomis@gmail.com>
* [bitnami/redis] Fix data loss when executing failover
Signed-off-by: Jota Martos <jotamartos@vmware.com>
* [bitnami/redis] Add comment to provide more information regarding the actions that will be executed
Signed-off-by: Jota Martos <jotamartos@vmware.com>
* Update comments in the script
Signed-off-by: jota <jota@bitnami.com>
* Run failover command in the redis server to decrease the service interruption time
Signed-off-by: jotamartos <jotamartos@vmware.com>
* Do not run the client pause command if failover is run
Signed-off-by: jotamartos <jotamartos@vmware.com>
* Use one single node to avoid issues with the resilience-tests
Signed-off-by: jotamartos <jotamartos@vmware.com>
Signed-off-by: Jota Martos <jotamartos@vmware.com>
Signed-off-by: jota <jota@bitnami.com>
Signed-off-by: jotamartos <jotamartos@vmware.com>
* Generic README instructions related to the repo
Signed-off-by: Carlos Rodríguez Hernández <carlosrh@vmware.com>
* Change repo in more commands
Signed-off-by: Carlos Rodríguez Hernández <carlosrh@vmware.com>
* Minor changes
Signed-off-by: Carlos Rodríguez Hernández <carlosrh@vmware.com>
* Revert URL removal
Signed-off-by: Carlos Rodríguez Hernández <carlosrh@vmware.com>
Signed-off-by: Carlos Rodríguez Hernández <carlosrh@vmware.com>
* [bitnami/redis] Allow configuring podTargetLabels on serviceMonitor
Signed-off-by: Bob Van Landuyt <bob@vanlanduyt.co>
* [bitnami/redis] Bump chart from 17.1.8 to 17.2.0
Signed-off-by: Bob Van Landuyt <bob@vanlanduyt.co>
Signed-off-by: Bob Van Landuyt <bob@vanlanduyt.co>
Without this change, in order to use a custom probe, the user has to
specify the probe parameters, and also must specify for the original
probe "enabled: false".
Issue: #12354
Signed-off-by: Orgad Shaneh <orgad.shaneh@audiocodes.com>
Signed-off-by: Orgad Shaneh <orgad.shaneh@audiocodes.com>
* redis: change default sentinel.failoverTimeout to match documentation
See https://redis.io/docs/manual/sentinel/#configuring-sentinel
Signed-off-by: Adam Snyder <armsnyder@gmail.com>
* redis: More renaming slave to replica
This should be backward-compatible, since the script still supports both "slave" and "replica" `REDIS_REPLICATION_MODE` values.
Signed-off-by: Adam Snyder <armsnyder@gmail.com>
* redis: Fix sentinel readiness probe timeout
Timeout was copy-pasted from liveness probe.
Signed-off-by: Adam Snyder <armsnyder@gmail.com>
* Fix redis configuration value changes not taking effect
I found and removed all `if [[ ! -f` checks which were preventing updates to the ConfigMap from getting into the redis config files.
Signed-off-by: Adam Snyder <armsnyder@gmail.com>
* Bump redis chart version to 17.1.2
Signed-off-by: Adam Snyder <armsnyder@gmail.com>
* bitnami/redis: Change "slave" to "replica" in start-sentinel.sh
Signed-off-by: Adam Snyder <armsnyder@gmail.com>
Signed-off-by: Adam Snyder <armsnyder@gmail.com>
