Redis Cluster default values file contains Helm markup
Name and Version
bitnami/redis-cluster 10.2.3
What architecture are you using?
amd64
What steps will reproduce the bug?
- Deploying a new cluster by enabling metrics
metrics.enabled=true - View the
prometheus.io/portannotation on pods and observe the value is{{ .Values.metrics.containerPorts.http }} - View the pod logs and see errors about "Possible SECURITY ATTACK detected" and "Bad message length..." because the prometheus scraper is making connections to the wrong port.
Are you using any custom parameters or values?
--set metrics.enabled=true
What is the expected behavior?
The expected behavior is the pod annotation for prometheus.io/port be valid. The values.yaml file is not rendered by helm thus helm values references cannot be used in values file. I would expect the default value to match the default value for the port, annotations:
prometheus.io/port: 9121
prometheus.io/scrape: 'true'
What do you see instead?
Annotations:
prometheus.io/port: '{{ .Values.metrics.containerPorts.http }}'
prometheus.io/scrape: 'true'
Additional information
I see this pattern in a number of the other bitnami helm charts. In general, do not use helm {{ .Values.something }} in the value files directly. Either use defaults or add helm logic in the templates to pull the correct value from the other property, ie {{ .Values.metrics.containerPorts.http }}
Hi, for some reason, I do not reproduce your issue. This is what I tried:
$ helm template oci://registry-1.docker.io/bitnamicharts/redis-cluster --version 10.2.3 --set metrics.enabled=true | grep prometheus.io
prometheus.io/port: '9121'
prometheus.io/scrape: "true"
The output I'm obtaining is the expected one, right?. Not sure why you are hitting the described issue...
I will start with a clean environment and try to reproduce.
This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.
Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.