Current behaviour
The chart installs all 10 CRDs as a single all-or-nothing block:
# values.yaml
crds:
create: true # all or nothing, no per-CRD control
The entire templates/crds/crds.yaml (18k lines, 10 CRDs) is wrapped in a single {{- if .Values.crds.create }} gate.
Expected behaviour
Allow per-CRD toggles so operators can install only what they use:
crds:
clusters: true
backups: false
scheduledbackups: false
poolers: false
databases: false
publications: false
subscriptions: false
imagecatalogs: false
clusterimagecatalogs: false
failoverquorums: false
Why this matters
In multi-tenant clusters where a platform team governs cluster-scoped resources, clients must justify every CRD registered with the API server. In practice, most deployments only use clusters (and optionally backups / scheduledbackups). The remaining 7 CRDs are installed but never instantiated, which creates an unnecessary audit surface in regulated environments.
Workaround today
Set crds.create: false and manage CRDs manually outside the chart — but this breaks automated CRD upgrades on chart updates.
Current behaviour
The chart installs all 10 CRDs as a single all-or-nothing block:
The entire
templates/crds/crds.yaml(18k lines, 10 CRDs) is wrapped in a single{{- if .Values.crds.create }}gate.Expected behaviour
Allow per-CRD toggles so operators can install only what they use:
Why this matters
In multi-tenant clusters where a platform team governs cluster-scoped resources, clients must justify every CRD registered with the API server. In practice, most deployments only use
clusters(and optionallybackups/scheduledbackups). The remaining 7 CRDs are installed but never instantiated, which creates an unnecessary audit surface in regulated environments.Workaround today
Set
crds.create: falseand manage CRDs manually outside the chart — but this breaks automated CRD upgrades on chart updates.