Request
Publish the chart's CRDs as a separate Helm chart (e.g. nvsentinel-crds) alongside the main chart.
Why
Helm installs a chart's crds/ directory on first install and never touches it again on upgrade (Helm docs: limitations on CRDs). So a chart bump whose CRDs changed pairs a new controller with the previous schema: the API server silently prunes writes to fields the old schema does not know, and the controller keeps reporting healthy while dropping data. Nothing in the upgrade reports it.
The workaround every consumer ends up with is a manual kubectl apply of the CRDs before the upgrade, which is easy to forget and hard to verify.
A separate CRDs chart removes the problem instead of documenting it: the CRDs become an ordinary release that Helm upgrades normally, and consumers can order it ahead of the main chart. It is the established pattern in the ecosystem, and several charts we consume already do it, including prometheus-operator-crds, mariadb-operator-crds, and slinky-slurm-operator-crds.
Context
We deploy nvsentinel as part of NVIDIA AI Cluster Runtime (AICR), which generates Helm, Helmfile, Flux, and Argo CD bundles. Flux and Argo CD upgrade CRDs on their own; Helm and Helmfile cannot without extra machinery. A CRDs chart would let every deployer converge through the same ordinary release rather than each solving it separately.
Happy to contribute the change if that would help — it is usually a matter of moving crds/ into a sibling chart and publishing both. Related work on our side: NVIDIA/aicr#2525.
Request
Publish the chart's CRDs as a separate Helm chart (e.g.
nvsentinel-crds) alongside the main chart.Why
Helm installs a chart's
crds/directory on first install and never touches it again on upgrade (Helm docs: limitations on CRDs). So a chart bump whose CRDs changed pairs a new controller with the previous schema: the API server silently prunes writes to fields the old schema does not know, and the controller keeps reporting healthy while dropping data. Nothing in the upgrade reports it.The workaround every consumer ends up with is a manual
kubectl applyof the CRDs before the upgrade, which is easy to forget and hard to verify.A separate CRDs chart removes the problem instead of documenting it: the CRDs become an ordinary release that Helm upgrades normally, and consumers can order it ahead of the main chart. It is the established pattern in the ecosystem, and several charts we consume already do it, including
prometheus-operator-crds,mariadb-operator-crds, andslinky-slurm-operator-crds.Context
We deploy nvsentinel as part of NVIDIA AI Cluster Runtime (AICR), which generates Helm, Helmfile, Flux, and Argo CD bundles. Flux and Argo CD upgrade CRDs on their own; Helm and Helmfile cannot without extra machinery. A CRDs chart would let every deployer converge through the same ordinary release rather than each solving it separately.
Happy to contribute the change if that would help — it is usually a matter of moving
crds/into a sibling chart and publishing both. Related work on our side: NVIDIA/aicr#2525.