monitoring: chart comment, OIDC guide and test fixture all encode a release name production never produces #3338

packages/system/monitoring derives the Grafana OIDC clientId, audience-scope name, client-secret name and users-Job name from the release name:

{{- define "monitoring.oidc.clientId" -}}
{{- printf "%s-%s" .Release.Namespace .Release.Name -}}
{{- end -}}

Three places in the tree state or imply that release is named monitoring, yielding <ns>-monitoring. In a running cluster it is always monitoring-system, yielding <ns>-monitoring-system. Nothing breaks at runtime — the templates are self-consistent whatever the release is called — but the tree misdescribes its own output in three places that look independent and share one ancestor, and readers trust them. Reviewing cozystack/website#597 I used two of them as evidence and filed a blocker saying the docs had the clientId wrong. The docs were right; the comment and the test fixture were both wrong.

What the release is actually called

packages/apps/tenant/templates/monitoring.yaml creates HelmRelease monitoring in the tenant namespace, pointing at extra/monitoring. That chart's check-release-name.yaml hard-fails unless its release is named monitoring, and its templates/helmrelease.yaml then creates the inner HelmRelease:

metadata:
  name: {{ .Release.Name }}-system

That inner HelmRelease is the one carrying system/monitoring (the monitoring-system component of cozystack.monitoring-application). It sets neither spec.releaseName nor spec.targetNamespace, and Flux defaults spec.releaseName to [<target namespace>-]<name>. So inside system/monitoring the release is monitoring-system and the namespace is the tenant's — in every namespace, tenant and platform alike. The clientId is <ns>-monitoring-system; there is no release named monitoring that renders OIDC at all.

The three places

1. packages/system/monitoring/templates/_helpers.tpl, header comment:

    tenant-foo/monitoring        (per-tenant Grafana in tenant-foo ns)
    cozy-monitoring/monitoring-system  (platform Grafana in cozy-monitoring ns)

Both lines are wrong, in opposite directions. The per-tenant release is monitoring-system, and the platform Grafana is the root tenant's — it lives in tenant-root, not cozy-monitoring. packages/system/cozystack-basics/templates/monitoring-external-services.yaml says so outright: "These ExternalName Services live in cozy-monitoring and redirect vlinsert-generic / vminsert-* to the platform monitoring stack the root tenant hosts in tenant-root." packages/core/platform/templates/bundles/system.yaml agrees: "The platform Grafana's HelmRelease is created by the tenant-root chart's templates/monitoring.yaml".

2. docs/oidc-grafana.md:4 places the platform release in cozy-monitoring. The release name is right there; the namespace is not.

3. packages/system/monitoring/tests/oidc_test.yaml, suite fixture:

release:
  name: monitoring
  namespace: tenant-root

The namespace is correct — that is where the platform release lives. The name is not, so the suite pins tenant-root-monitoring as the clientId and tenant-root-monitoring-audience as the scope name, where a cluster renders tenant-root-monitoring-system and tenant-root-monitoring-system-audience. The assertions are precise and green; the input is one no cluster produces. helm-unittest cannot catch this on its own — release.name is a fixture, not a derived fact, and for a chart whose release name is assigned by a parent chart's HelmRelease that fixture is an unverifiable assumption about the caller.

Where the belief likely comes from

packages/core/platform/sources/monitoring.yaml declares a cozystack.monitoring PackageSource whose monitoring component installs system/monitoring with install: {namespace: cozy-monitoring, releaseName: monitoring} — exactly the naming the three places above describe. That source appears to be dead: the string cozystack.monitoring occurs exactly once in the whole tree, as its own metadata.name. No bundle emits a Package for it, and without a Package the reconciler never installs its components. Worth confirming, then removing it or recording why it stays.

Knock-on for #3259

Detail B of #3259 rests on the same premise: "The platform Monitoring release lives in cozy-monitoring, not a tenant-* namespace, so the helper computes cozy-monitoring-{view,use,admin,super-admin} — groups that exist nowhere in the realm → every OIDC login locked out." If the platform release is in tenant-root, then monitoring.oidc.allowedGroups computes tenant-root-{view,use,admin,super-admin}, which the tenant chart does provision for the root tenant, and the described lockout does not exist. The namespace guard for non-tenant- releases in that issue's suggested scope may therefore be solving nothing. oidc_test.yaml corroborates the corrected reading: it uses namespace: tenant-root and asserts exactly those four groups.

Suggested fix

• Correct the _helpers.tpl header comment and docs/oidc-grafana.md:4.
• Change the oidc_test.yaml fixture to release.name: monitoring-system and update the expected clientId, audience-scope, client-secret and users-Job names so the suite pins what a cluster actually renders.
• Confirm whether the cozystack.monitoring PackageSource is dead, and remove it if it is.
• Re-check Detail B of OIDC group gate: extend to ancestor tenants + guard platform Monitoring release #3259 against the corrected topology.