Context
The CA extraction controller (#3286) needs a per-engine name-fallback, because neither CloudNativePG nor Percona PSMDB will apply a custom label to the CA Secret they create themselves. Verified against the shipped versions: CNPG 1.27.1 has spec.inheritedMetadata, but internal/controller/cluster_pki.go never calls SetInheritedData(), so the PKI secrets silently opt out of it while the credential secrets opt in; PSMDB 1.22.0 builds its cert-manager Certificate in code without ever setting SecretTemplate, exposes no field naming the CA Secret, and reconciles away any out-of-band patch through its percona.com/last-config-hash mechanism.
The alternative, for postgres only
CNPG supports bringing your own CA and server certificate through spec.certificates.serverCASecret and serverTLSSecret. The postgres chart could mint both with cert-manager — stamping internal.cozystack.io/publish-ca-cert: "true" via Certificate.spec.secretTemplate.labels — and hand them to the operator. Postgres would then sit on the same pure label-driven path as nats and qdrant, with no entry in the controller's fallback config.
Why this is a follow-up and not part of the first convergence
The fallback mechanism has to exist regardless. PSMDB has no path at all, so converting postgres does not let us delete the fallback — it only removes one entry from its configuration. The clean-contract argument is therefore much weaker than it first appears: the contract is already two-legged because of mongodb.
Against that, the conversion is a real change. It moves postgres from operator-managed PKI to chart-managed PKI, which raises a migration question for existing clusters. It also cannot be done by half: serverCASecret alone is insufficient, because a cert-manager CA Secret carries tls.key rather than ca.key, so serverTLSSecret must be supplied alongside it — this is CNPG's documented pairing, not a workaround. And because DefaultServerCaSecretSuffix and ClientCaSecretSuffix are both -ca, CNPG still generates its own <cluster>-ca for client certificates when clientCASecret is unset, so the operator-minted key-bearing Secret keeps existing as an internal artifact either way.
The field semantics above come from the CRD schema, upstream documentation and source constants. This path has not been exercised end-to-end on a cluster.
Decision
Revisit once the controller and the postgres convergence have landed and the real cost of the fallback is known. If the fallback turns out to be cheap and boring, this stays closed as unnecessary.
Part of #2811. Follow-up to #3286.
Context
The CA extraction controller (#3286) needs a per-engine name-fallback, because neither CloudNativePG nor Percona PSMDB will apply a custom label to the CA Secret they create themselves. Verified against the shipped versions: CNPG 1.27.1 has
spec.inheritedMetadata, butinternal/controller/cluster_pki.gonever callsSetInheritedData(), so the PKI secrets silently opt out of it while the credential secrets opt in; PSMDB 1.22.0 builds its cert-managerCertificatein code without ever settingSecretTemplate, exposes no field naming the CA Secret, and reconciles away any out-of-band patch through itspercona.com/last-config-hashmechanism.The alternative, for postgres only
CNPG supports bringing your own CA and server certificate through
spec.certificates.serverCASecretandserverTLSSecret. The postgres chart could mint both with cert-manager — stampinginternal.cozystack.io/publish-ca-cert: "true"viaCertificate.spec.secretTemplate.labels— and hand them to the operator. Postgres would then sit on the same pure label-driven path as nats and qdrant, with no entry in the controller's fallback config.Why this is a follow-up and not part of the first convergence
The fallback mechanism has to exist regardless. PSMDB has no path at all, so converting postgres does not let us delete the fallback — it only removes one entry from its configuration. The clean-contract argument is therefore much weaker than it first appears: the contract is already two-legged because of mongodb.
Against that, the conversion is a real change. It moves postgres from operator-managed PKI to chart-managed PKI, which raises a migration question for existing clusters. It also cannot be done by half:
serverCASecretalone is insufficient, because a cert-manager CA Secret carriestls.keyrather thanca.key, soserverTLSSecretmust be supplied alongside it — this is CNPG's documented pairing, not a workaround. And becauseDefaultServerCaSecretSuffixandClientCaSecretSuffixare both-ca, CNPG still generates its own<cluster>-cafor client certificates whenclientCASecretis unset, so the operator-minted key-bearing Secret keeps existing as an internal artifact either way.The field semantics above come from the CRD schema, upstream documentation and source constants. This path has not been exercised end-to-end on a cluster.
Decision
Revisit once the controller and the postgres convergence have landed and the real cost of the fallback is known. If the fallback turns out to be cheap and boring, this stays closed as unnecessary.
Part of #2811. Follow-up to #3286.