Summary
After #926 split prometheus-operator-crds out as its own release, several components that create monitoring.coreos.com/v1 CRs (PodMonitor / ServiceMonitor / etc.) rely on a multi-hop transitive dependency path rather than declaring a direct dependencyRefs edge. This is brittle.
Concrete example
nvsentinel's registry comment at recipes/registry.yaml:258-264 documents the chain:
nvsentinel depends on gpu-operator, which depends on kube-prometheus-stack, which depends on prometheus-operator-crds
If anyone removes the gpu-operator → kube-prometheus-stack edge in recipes/overlays/base.yaml — plausible since gpu-operator doesn't strictly need kube-prometheus-stack to install, only to scrape metrics — the helm-diff race on nvsentinel's PodMonitor CRD silently returns. No CI test catches it; the failure surfaces only on a fresh-cluster helmfile apply.
Why this matters
The whole thesis of #926 is "let dependencyRefs encode the ordering" — applying that consistently means every component whose templates create monitoring CRs should declare prometheus-operator-crds as a direct dependencyRefs entry. The DAG-flattening makes the extra edge a no-op when the transitive path already exists, but it survives refactors of intermediate nodes.
Acceptance Criteria
Related
Summary
After #926 split
prometheus-operator-crdsout as its own release, several components that createmonitoring.coreos.com/v1CRs (PodMonitor / ServiceMonitor / etc.) rely on a multi-hop transitive dependency path rather than declaring a directdependencyRefsedge. This is brittle.Concrete example
nvsentinel's registry comment atrecipes/registry.yaml:258-264documents the chain:If anyone removes the
gpu-operator → kube-prometheus-stackedge inrecipes/overlays/base.yaml— plausible since gpu-operator doesn't strictly need kube-prometheus-stack to install, only to scrape metrics — the helm-diff race on nvsentinel's PodMonitor CRD silently returns. No CI test catches it; the failure surfaces only on a fresh-clusterhelmfile apply.Why this matters
The whole thesis of #926 is "let
dependencyRefsencode the ordering" — applying that consistently means every component whose templates create monitoring CRs should declareprometheus-operator-crdsas a directdependencyRefsentry. The DAG-flattening makes the extra edge a no-op when the transitive path already exists, but it survives refactors of intermediate nodes.Acceptance Criteria
recipes/overlays/,recipes/mixins/, andrecipes/components/*/values.yamlfor charts whose templates emitmonitoring.coreos.com/v1resources (PodMonitor, ServiceMonitor, Alertmanager, AlertmanagerConfig, Prometheus, PrometheusRule, Probe, ThanosRuler).dependencyRefs: [prometheus-operator-crds]to each such component inrecipes/overlays/base.yaml(in addition to any existing edges).nvsentinelregistry comment inrecipes/registry.yamlto remove the "transitively satisfied" wording once the direct edge is in place.monitoring.coreos.com/v1CR (detectable by grepping rendered chart output) hasprometheus-operator-crdsreachable in itsdependencyRefsclosure.Related