Redis values not applied for second dependency in umbrella chart
We are deploying two oauth2-proxy instances (one for admin access and one for read-only access) using an umbrella Helm chart with two dependencies, like this:
dependencies:
- name: oauth2-proxy
version: 8.2.0
repository: "oci://ghcr.io/oauth2-proxy/charts"
alias: auth-read-only
- name: oauth2-proxy
version: 8.2.0
repository: "oci://ghcr.io/oauth2-proxy/charts"
alias: auth-admin
The problem: For the second dependency in the list, the Redis values are not being overridden as expected, and instead the defaults from the original Redis Helm chart are applied.
This issue did not occur in versions < 8.0, when the chart used Bitnami Redis.
@yuiri-sedykh, could you please provide a values.yaml example file to generate the error so we can reproduce it?
@pierluigilenoci Values for the test were taken from https://github.com/oauth2-proxy/manifests/blob/main/helm/oauth2-proxy/ci/redis-standalone-values.yaml
auth-read-only:
sessionStorage:
type: redis
redis:
clientType: "standalone"
password: "foo"
# provision an instance of the redis-ha sub-chart
redis:
enabled: true
redisPassword: "foo"
replicas: 1
# Remove sentinel overhead, speed up startup and redis itself
sentinel:
livenessProbe:
enabled: false
readinessProbe:
enabled: false
startupProbe:
enabled: false
quorum: 1
hardAntiAffinity: false
redis:
config:
min-replicas-to-write: 0
save: ""
appendonly: "no"
terminationGracePeriodSeconds: 10
livenessProbe:
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 3
failureThreshold: 2
readinessProbe:
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 3
failureThreshold: 2
startupProbe:
initialDelaySeconds: 5
periodSeconds: 2
timeoutSeconds: 3
failureThreshold: 10
splitBrainDetection:
interval: 60
persistentVolume:
enabled: false
emptyDir: {}
haproxy:
enabled: false
exporter:
enabled: false
sysctlImage:
enabled: false
hostPath:
chown: false
initContainers:
waitForRedis:
enabled: true
auth-admin:
sessionStorage:
type: redis
redis:
clientType: "standalone"
password: "foo"
# provision an instance of the redis-ha sub-chart
redis:
enabled: true
redisPassword: "foo"
replicas: 1
# Remove sentinel overhead, speed up startup and redis itself
sentinel:
livenessProbe:
enabled: false
readinessProbe:
enabled: false
startupProbe:
enabled: false
quorum: 1
hardAntiAffinity: false
redis:
config:
min-replicas-to-write: 0
save: ""
appendonly: "no"
terminationGracePeriodSeconds: 10
livenessProbe:
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 3
failureThreshold: 2
readinessProbe:
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 3
failureThreshold: 2
startupProbe:
initialDelaySeconds: 5
periodSeconds: 2
timeoutSeconds: 3
failureThreshold: 10
splitBrainDetection:
interval: 60
persistentVolume:
enabled: false
emptyDir: {}
haproxy:
enabled: false
exporter:
enabled: false
sysctlImage:
enabled: false
hostPath:
chown: false
initContainers:
waitForRedis:
enabled: true
@yuiri-sedykh I tested it, and it is true. The values are overwritten.
I used these files to generate it.
Chart.yaml
name: double-install
version: 0.0.1
apiVersion: v2
appVersion: 0.0.1
dependencies:
- name: oauth2-proxy
version: 8.2.0
repository: "oci://ghcr.io/oauth2-proxy/charts"
alias: auth-read-only
- name: oauth2-proxy
version: 8.2.0
repository: "oci://ghcr.io/oauth2-proxy/charts"
alias: auth-admin
values.yaml
auth-read-only:
fullnameOverride: "auth-read-only"
sessionStorage:
type: redis
redis:
clientType: "standalone"
password: "foo"
# provision an instance of the redis-ha sub-chart
redis:
enabled: true
redisPassword: "foo"
replicas: 1
# Remove sentinel overhead, speed up startup and redis itself
sentinel:
livenessProbe:
enabled: false
readinessProbe:
enabled: false
startupProbe:
enabled: false
quorum: 1
hardAntiAffinity: false
redis:
config:
min-replicas-to-write: 0
save: ""
appendonly: "no"
terminationGracePeriodSeconds: 10
livenessProbe:
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 3
failureThreshold: 2
readinessProbe:
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 3
failureThreshold: 2
startupProbe:
initialDelaySeconds: 5
periodSeconds: 2
timeoutSeconds: 3
failureThreshold: 10
splitBrainDetection:
interval: 60
persistentVolume:
enabled: false
emptyDir: {}
haproxy:
enabled: false
exporter:
enabled: false
sysctlImage:
enabled: false
hostPath:
chown: false
initContainers:
waitForRedis:
enabled: true
auth-admin:
fullnameOverride: "auth-admin"
sessionStorage:
type: redis
redis:
clientType: "standalone"
password: "foo2"
# provision an instance of the redis-ha sub-chart
redis:
enabled: true
redisPassword: "foo2"
replicas: 2
# Remove sentinel overhead, speed up startup and redis itself
sentinel:
livenessProbe:
enabled: false
readinessProbe:
enabled: false
startupProbe:
enabled: false
quorum: 2
hardAntiAffinity: false
redis:
config:
min-replicas-to-write: 0
save: ""
appendonly: "no"
terminationGracePeriodSeconds: 11
livenessProbe:
initialDelaySeconds: 6
periodSeconds: 6
timeoutSeconds: 4
failureThreshold: 3
readinessProbe:
initialDelaySeconds: 6
periodSeconds: 6
timeoutSeconds: 4
failureThreshold: 3
startupProbe:
initialDelaySeconds: 6
periodSeconds: 3
timeoutSeconds: 4
failureThreshold: 11
splitBrainDetection:
interval: 61
persistentVolume:
enabled: false
emptyDir: {}
haproxy:
enabled: false
exporter:
enabled: false
sysctlImage:
enabled: false
hostPath:
chown: false
initContainers:
waitForRedis:
enabled: true
@DandyDeveloper @tuunit I analyzed the two charts, but I didn't find anything explicitly wrong that wouldn't work.
@yuiri-sedykh This seemed strange, so I investigated further, and it might be a problem with Helm itself. Ref: https://github.com/helm/helm/issues/9052
Are you sure it worked before with the old Redis chart?
A new feature to handle this is https://github.com/helm/helm/pull/9175, which will be included in Helm v4. A request to backport it to Helm v3 is still open. https://github.com/helm/helm/pull/30802
Could this be the solution to your problem?
@pierluigilenoci it worked before. I wanted to update this chart version because of Bitnami, but ran into this issue. As a workaround, I’m just using a < 8.0 chart with the legacy Bitnami Redis image name overridden.
While investigating, I found this closed Helm issue—maybe it’s somehow related to the fullname usage in the new Redis chart? https://github.com/helm/helm/issues/9789#issuecomment-858631525
I guess this might be due to the fact that we don't use the chart name redis-ha but instead the configured alias redis 🤔
Please try with redis-ha: in your values file.
But this might break the helper templating for the fullname of redis
https://github.com/oauth2-proxy/manifests/blob/77311c0aa5a223068ac59d2309644f47b78fb8f2/helm/oauth2-proxy/templates/_helpers.tpl#L97
@tuunit That was exactly the code I was experimenting with. Is there a simple way to fix this?
I'm having a similar issue. I put redis.enabled = false in both my aliasa subcharts but it still gets deployed
Seems we have to wait for helm v4. fix:
- https://github.com/helm/helm/pull/9184
backport:
- https://github.com/helm/helm/pull/30802
After upgrading to Helm 4, the issue disappeared. Thanks.
@yuiri-sedykh, can we close this now?
@pierluigilenoci, yes, sure. Thanks
Here a commit to use helm v4 in a github action: https://github.com/ecamp/ecamp3/commit/86591aaa04af62dff7c0dd1f40148238d308afd1