[jtslear]

kube-state-metrics and prometheus-node-exporter were dependencies of the prometheus subchart, so disabling prometheus also dropped them, and there is no way to disable only the Prometheus server. That blocks running just the collector side (Alloy, kube-state-metrics, node-exporter) in a cluster whose metrics go to a Prometheus elsewhere.

This makes both top-level dependencies with their own enabled flags. The prometheus chart's copies are disabled.

• Same chart versions as before (kube-state-metrics 8.0.0, prometheus-node-exporter 4.56.1, pinned to what prometheus 29.20.1 resolved to).
• fullnameOverride, pod annotations and node-exporter's containerSecurityContext/rbac defaults (which came from the prometheus chart) move with them.
• With default values the rendered output is semantically identical: I normalised and compared the old and new compiled/resources.yaml resource by resource, and there are no differences. The compiled/ diff is only resource ordering.

BREAKING for values overrides: prometheus.kube-state-metrics.* and prometheus.prometheus-node-exporter.* become top-level kube-state-metrics.* and prometheus-node-exporter.* (noted in the CHANGELOG). The dogfood repo's metricLabelsAllowlist override is the only one I know of.

• The chart now fails to render when an old-style override is still set under prometheus.kube-state-metrics or prometheus.prometheus-node-exporter (other than the chart's own enabled, rbac and containerSecurityContext defaults), so it can't be ignored silently.
• node-exporter is pinned to exactly 4.56.1 on purpose (4.56.3 changes its default flags) and no longer follows the prometheus chart; bump it by hand.
• This change alone does not make prometheus.enabled: false render. That needs feat: let the collector write to a Prometheus outside the release #102 (global.telemetry.metrics.remoteWriteURL); the two are meant to ship together.

🤖 Generated with Claude Code