2 Commits

Include renames

Author	SHA1	Message	Date
volker.raschekandCopilot	6d68d44894	feat(cloudnativePG): support topologySpreadConstraints ... A HA `Cluster` is only actually highly available if its instances end up in different failure domains. Pod anti-affinity alone cannot express that: it only keeps the instances off the same node, not off the same zone, and `cloudnativePG.affinity` has no way to encode a skew budget. Without `topologySpreadConstraints` a three instance cluster can legitimately be scheduled into a single availability zone, where a zone outage takes down the primary and both replicas at once. Both `affinity` and `topologySpreadConstraints` are rendered only when they are set. The CloudNativePG API declares them as `omitempty`, so an empty `{}` or `[]` in the manifest would show up as a permanent diff against the state the operator writes back. Tolerations deliberately do not get a dedicated value. CloudNativePG has no `spec.tolerations`, it nests them below `spec.affinity.tolerations`, so they are configured through `cloudnativePG.affinity` like `nodeSelector` and the anti-affinity settings. A separate top-level value would only have to be folded back into the same place and would silently conflict with a tolerations list set via `cloudnativePG.affinity`. Co-authored-by: Copilot <copilot@github.com>	2026-10-04 00:39:08 +02:00
volker.raschekandCopilot	1b82a15b7f	feat!: replace postgresql-ha with CloudNativePG ... The bundled `postgresql-ha` sub-chart was the only HA-ready database option, but it pinned us to a Bitnami chart whose images are no longer freely distributed, and it bundled repmgr and pgpool into the release. Operating a Postgres cluster through a Helm release also means the chart has to reimplement failover, backup and upgrade orchestration that a dedicated operator already solves. CloudNativePG is the de-facto standard operator for Postgres on Kubernetes and handles instance management, streaming replication, switchover and rolling upgrades itself. The operator is deliberately *not* part of this chart: cluster-scoped CRDs and controllers do not belong into an application release and would conflict with an operator that is already installed. The chart only renders the namespaced `Cluster` resource, so the operator can be managed independently. Because the operator cannot be assumed to be present, `cloudnativePG.enabled` defaults to `false`. Existing users of `postgresql` or an external database are therefore unaffected. Credentials follow the chart-wide `secrets.*` convention. Only the password is read from a Secret, because CloudNativePG requires `bootstrap.initdb.database` and `bootstrap.initdb.owner` as literals in the `Cluster` spec and cannot resolve them from a Secret. The password is injected into the `init-app-ini` container as `GITEA__database__PASSWD` instead of being written into the generated `app.ini`. BREAKING CHANGE: The `postgresql-ha` sub-chart and all `postgresql-ha.*` values have been removed. There is no in-place migration path between the two deployments: dump the database of the old `postgresql-ha` release with `pg_dump`, remove the `postgresql-ha` values, deploy the chart with `cloudnativePG.enabled=true` and restore the dump. Setting `postgresql-ha` now fails the release with a pointer to the changelog. Co-authored-by: Copilot <copilot@github.com>	2026-10-04 00:18:34 +02:00