[bmscomp]

Why

cdc-postgresql (#474) hasn't been published yet: GHCR has no charts/cdc-postgresql. Its first published version should be one we're happy to keep, since a published version is never re-pushed. Three things in 0.1.0 were worth fixing first:

• It ran the moving postgres:16 tag, so a reinstall could get a different server.
• It took any values.
• Nothing checked the settings the connectors depend on.

What

cdc-postgresql 0.1.0 → 0.2.0:

• Pinned image: postgres:16.15 (appVersion 16.15). An optional image.digest pins by content.
• values.schema.json refuses:
  • unknown keys;
  • a latest tag;
  • a malformed digest;
  • postgres as the CDC user;
  • parameters that would override wal_level, max_wal_senders or max_replication_slots.
• helm test connects through the Service as the CDC user, the way Debezium does. It checks wal_level=logical, the user's REPLICATION attribute, and that the user owns the database.
• New options, all off by default:
  • parameters: extra -c name=value server settings;
  • persistence.enabled=false: the data in an emptyDir;
  • networkPolicy.enabled: admits 5432 only from the namespaces and pods listed, plus the chart's own test.
• Hardening:
  • a startup probe covers the first start's initdb;
  • the probes check the TCP listener;
  • the root filesystem is read-only, since postgres writes only to its mounted volumes;
  • NOTES.

What deploy relies on is unchanged: the release name, the Service, the app.kubernetes.io/name=postgresql label, and the Secret keys postgres-password and password. The default credentials stay, because deploy writes debezium into Connect's connect-pg-credentials. Moving to generated or existing-Secret credentials needs a CLI change too, so it's left for later.

Publishing

After this merges, dispatching publish-charts.yml from main publishes cdc-postgresql 0.2.0, signed and attested under the main-branch identity that kates deploy accepts. That way the package exists, and can be made public, before v1.30.0 (#479). The dispatch also publishes the six other chart versions main has but GHCR doesn't: kafka-cluster 1.0.18, kafka-ui 0.3.2, kates-platform 0.8.7, kates 0.14.1, kates-monitoring 1.7.1 and strimzi-operator 0.4.5.

Tests

• helm lint. The schema refuses each bad value above and accepts a good one.
• check-chart-policies.sh cdc-postgresql: PASS, test pod included.
• chart_bumps.py, check-versions.sh, gen-chart-table.sh --check, gen-version-matrix.sh --check, yamllint.
• On a scratch kind cluster, in namespaces that enforce restricted Pod Security:
  • the default install is Ready and helm test passes;
  • a second release with persistence.enabled=false, networkPolicy.enabled=true and parameters.max_connections=150 creates no PVC, passes helm test, and reports SHOW max_connections = 150;
  • an unlisted namespace gets "no response" on 5432, and after it is added to allowNamespaces it gets "accepting connections".
• Not rerun: a full kates deploy --with-kafka-connect with Debezium. Deploy passes no values to this chart, and its defaults keep every name and key Connect and the Kates API use.