Prometheus High-Fanout Demo

This generated demo uses prometheus-community/kube-prometheus-stack@85.3.3 to show why some Helm choices belong in reviewed base variants instead of ad hoc post-render edits.

Base Variants

The no-crds base changes one render-time choice:

crds.enabled=false

That removes 10 CRD objects from the rendered set. It does not remove the Prometheus custom resources that use those CRDs. The current GitOps/OCI receipt records pass because Argo pulled the ConfigHub OCI artifact after the compatible CRDs and admission Secret were staged as target facts. The preserved older Flux receipt records a useful blocker: the same base cannot become live-ready on a target where those prerequisites are absent.

Chain Of Proof Status

This is the chain-of-proof lesson. The no-crds base is not semantically wrong: it passes two-cluster kind parity and strict ConfigHub OCI/Argo parity when CRDs and the admission Secret are staged as target facts. It is also correct for the older runtime GitOps wave to block when those CRDs are absent.

Value Reachability

The value-source map records two user-visible inputs and the rendered fields they affect:

This is deliberately small. It does not claim a full inverse map for the whole chart. It shows how high-value choices can become explicit graph edges instead of disappearing into rendered YAML.

For a compact pre-ship view of those choices, see:

data/high-fanout-demo/operation-preview.md

Removed Objects

How To Use The Example

Use this as the pattern for high-fanout charts:

1. Make render-time choices explicit as base variants.
2. Compare the rendered object inventory before promotion.
3. Keep target prerequisites visible, such as pre-existing CRDs and separated Secrets.
4. Treat blocked live receipts as useful evidence, not noise.

The lesson is not "always install CRDs with the chart." The lesson is that default and no-crds are different deployable contracts. One release owns the CRDs. The other assumes the target already provides them.

Next Hard Work

For production support, the default base has a narrow target-scoped supported decision. The no-crds base now has target-scoped support evidence for the staged-CRD and admission-Secret path, but it still needs a separate decision before it should be described as supported. Broader environments still need their own decision for CRD ownership, admission Secret source, webhook freshness checks, RBAC and scrape scope, storage posture, and the supported delivery path.

Production Support Checklist

This chart is the serious-chart proof path. The current evidence makes the base choices reviewable; it does not mark either base production-supported for all targets. Production support remains target-scoped.

Use default when the catalog package should own the CRDs. Use no-crds only when CRDs are a target prerequisite with their own owner, version, and fresh observation. The two bases are both valid review inputs, but they are not the same operational contract.

Files

Regenerate:

npm run high-fanout:generate
npm run high-fanout:verify