nextcloud.openmetrics.allowedClients is silently ignored unless nextcloud.configs is set
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 78/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- helm, kubernetes
- Domain
- devops, infrastructure
Research direction
Read charts/nextcloud/templates/_helpers.tpl and templates/config.yaml, focusing on the defaultConfigs guard and ConfigMap rendering. Render the chart with openmetrics.allowedClients set while nextcloud.configs is empty, then verify that helm-metrics.config.php is mounted and the setting is available to Nextcloud without unrelated configuration.
Written by the indexing model from the issue text.
Description
Describe the bug
nextcloud.openmetrics.allowedClients renders OPENMETRICS_ALLOWED_CLIENTS into the app
container, but nothing in the pod ever reads it. The only reader is
files/defaultConfigs/helm-metrics.config.php.tpl, and the defaultConfigs files are only
mounted when nextcloud.configs is non-empty
(_helpers.tpl#L431);
templates/config.yaml renders no ConfigMap at all otherwise.
So with the chart's default nextcloud.configs: {}, setting allowedClients does nothing:
Nextcloud keeps its built-in default of 127.0.0.1 only, and Prometheus is refused with 403.
This is the same gate reported in #761, but it bites differently here. The argument there for
keeping it — "normally you do not need the defaultConfig, because the files are already part of
the container image" — does not hold for helm-metrics.config.php. Like imaginary.config.php,
it is a chart file, not one of nextcloud/docker's.
There is no image copy to fall back on, so nextcloud.openmetrics.allowedClients cannot work on
its own under any configuration.
It also affects the chart's own defaults: prometheus.serviceMonitor selects the app Service as
well as the exporter Service, so an out-of-the-box metrics.enabled: true +
prometheus.serviceMonitor.enabled: true install scrapes /metrics on the app pod, gets a 403,
and sits with a permanently down target firing TargetDown.
Steps to reproduce
nextcloud:
openmetrics:
allowedClients:
- "127.0.0.1"
- "10.244.0.0/16" # your pod CIDR
metrics:
enabled: true
prometheus:
serviceMonitor:
enabled: true
$ kubectl exec deploy/nextcloud -c nextcloud -- sh -c 'echo $OPENMETRICS_ALLOWED_CLIENTS'
127.0.0.1,10.244.0.0/16
$ kubectl exec deploy/nextcloud -c nextcloud -- ls /var/www/html/config/
apache-pretty-urls.config.php apcu.config.php apps.config.php autoconfig.php
config.php config.sample.php redis.config.php reverse-proxy.config.php
s3.config.php smtp.config.php swift.config.php upgrade-disable-web.config.php
# no helm-metrics.config.php
$ kubectl exec deploy/nextcloud -c nextcloud -- sh -c 'cd /var/www/html && php occ config:system:get openmetrics_allowed_clients'
# unset
$ # from a pod whose IP is inside the CIDR above
$ curl -o /dev/null -w '%{http_code}\n' http://<nextcloud-pod-ip>:80/metrics
403
Adding any entry to nextcloud.configs makes it work, which is the tell.
Expected behaviour
Setting nextcloud.openmetrics.allowedClients configures openmetrics_allowed_clients, without
also having to set an unrelated value.
Possible fix
Drop the {{- if .Values.nextcloud.configs }} guard around the defaultConfigs loop in
_helpers.tpl and around the ConfigMap in config.yaml, as #761 asks. At minimum,
helm-metrics.config.php and imaginary.config.php need to mount whenever they are enabled,
since neither exists in the container image.
Versions
- Chart 9.3.0 (the guard is still on
main) - Nextcloud 34.0.4,
apacheflavor - Kubernetes 1.37.0, kube-prometheus-stack
- Dominant language
- Go Template
- Stars
- 536
- Forks
- 316
- Avg merge
- 4d 16h
- Merged PRs (30d)
- 2
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from nextcloud/helm
-
No native support for REDIS_USER enviroment varPossibly taken @jholmes802 claimed this 4 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
External Redis not working: redis-session.ini: Permission deniedPossibly taken @antoinetran claimed this 25 days ago. Open
Difficulty 3/5 1-2 days Newbie friendliness 55/100
-
Difficulty 3/5 1-2 days Newbie friendliness 55/100
Similar issues
-
track: dx
Difficulty 1/5 1-3 hours Newbie friendliness 76/100
-
follow-up main-defect wave-A
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
carrick-sh/carrick#249 ·
Maintainers usually reply within 1 day
-
bug good first issue javascript
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
yukikotani231/sqlsift#326 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
plengauer/RicherPresence#132 ·
Maintainers usually reply within 1 day
-
allows image
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
DaoCloud/public-image-mirror#46209 · 1 comment ·
Maintainers usually reply within 1 day