feat!: remove the postgresql sub-chart
With `cloudnativePG` in place, the bundled Bitnami `postgresql` sub-chart is the second in-chart way to run a database, and the worse one. It is a single, non-HA instance without failover, backup or managed major-version upgrades, and it ships images that Bitnami no longer distributes freely. Keeping it around means maintaining two code paths for the same job, including the mutual-exclusion assertion between both dependencies and a second set of DNS, credential and image helpers. Removing it leaves exactly two supported choices: a CloudNativePG `Cluster` rendered by this chart, or an external database configured via `gitea.config.database`. Both scale from a single instance to a HA setup - `cloudnativePG.instances=1` covers the use case the `postgresql` sub-chart served - so nothing is lost besides the duplication. BREAKING CHANGE: The `postgresql` sub-chart and all `postgresql.*` values have been removed. There is no in-place migration path: dump the database of the old `postgresql` release with `pg_dump`, remove the `postgresql` values, deploy the chart with `cloudnativePG.enabled=true` and restore the dump. Alternatively point `gitea.config.database` at an externally managed database. Setting `postgresql` now fails the release with a pointer to the changelog. Co-authored-by: Copilot <copilot@github.com>
This commit is contained in:
+3
-5
@@ -28,8 +28,8 @@ In addition, the following components are required for full HA-readiness:
|
||||
- A HA-ready cache (`valkey-cluster`)
|
||||
- A HA-ready DB
|
||||
|
||||
`postgresql.enabled`, which defaults to `false`, must stay disabled for a HA setup.
|
||||
The `postgresql` chart dependency is not HA-ready, use the `cloudnativePG` option instead.
|
||||
`cloudnativePG.enabled`, which defaults to `false`, must be enabled for a HA setup.
|
||||
It requires the CloudNativePG operator to be installed cluster-wide beforehand.
|
||||
|
||||
The following sections discuss each of the components in more detail.
|
||||
Note that for each component discussed, the shown configurations only provides a (working) starting point, not necessarily the most optimal setup.
|
||||
@@ -171,13 +171,11 @@ cloudnativePG:
|
||||
```
|
||||
|
||||
If you do not want to run the operator, using a managed database service in the cloud might be the easiest and most robust solution.
|
||||
Remember: keep `cloudnativePG` and `postgresql` disabled and configure the database connection manually via `gitea.config.database`:
|
||||
Remember: keep `cloudnativePG` disabled and configure the database connection manually via `gitea.config.database`:
|
||||
|
||||
```yml
|
||||
cloudnativePG:
|
||||
enabled: false
|
||||
postgresql:
|
||||
enabled: false
|
||||
|
||||
gitea:
|
||||
config:
|
||||
|
||||
Reference in New Issue
Block a user