Summary
An in-place restore of a platform-flow Postgres (backup.useSystemBucket: true) cannot converge: the RestoreJob's CNPG driver patches the app with bootstrap.enabled: true, but the chart hard-fails rendering when bootstrap.enabled && backup.useSystemBucket, and the driver's partial app schema can neither carry nor clear useSystemBucket. The app's HelmRelease is left failing until an operator manually flips backup.useSystemBucket off.
Flagged by IvanHunters during review of #3313 (#3313 (review)); it is pre-existing on main (both the guard and the patch shape predate that PR's merge-base), so it was split out rather than fixed there.
Evidence
- Chart guard (
packages/apps/postgres/templates/db.yaml): {{- if and .Values.bootstrap.enabled .Values.backup.useSystemBucket }}{{- fail "postgres: bootstrap.enabled=true is incompatible with backup.useSystemBucket=true. Use a backups.cozystack.io/RestoreJob against the cozy-default BackupClass to restore from the system bucket; ..." }} — note the message recommends exactly the RestoreJob path that then trips this guard.
- Driver partial schema (
internal/backupcontroller/postgresapp/types.go): PostgresSpec.Backup has no useSystemBucket field ("Add new fields here only when the driver genuinely needs them; everything else stays on the server, untouched by the controller's patches"), so the restore patch leaves the live useSystemBucket: true in place while setting bootstrap.enabled: true and the legacy restore coordinates.
- Result: the patched values combine
bootstrap.enabled: true with useSystemBucket: true, the chart render fails, and the HelmRelease (remediation retries -1) loops on the same render error forever — the restore never completes and the guard's own error message is what the operator sees.
Impact
- Restoring a
useSystemBucket: true Postgres in place (RestoreJob targeting the same release) wedges the release. Restore into a fresh release name works only if the new app is created without useSystemBucket.
Proposed fix (pick one)
- Add
useSystemBucket to the driver's partial app schema and have the restore patch explicitly set it to false (the restore patch already supplies the full legacy coordinates, so the semantics stay consistent), restoring it after the bootstrap completes if desired; or
- Teach the chart to tolerate
bootstrap.enabled && useSystemBucket when the restore coordinates are fully supplied (the guard exists to catch missing coordinates, not the driver-managed restore); or
- Have the driver clear
bootstrap and re-assert useSystemBucket as part of restore finalization, making the combination transient by construction.
Summary
An in-place restore of a platform-flow Postgres (
backup.useSystemBucket: true) cannot converge: the RestoreJob's CNPG driver patches the app withbootstrap.enabled: true, but the chart hard-fails rendering whenbootstrap.enabled && backup.useSystemBucket, and the driver's partial app schema can neither carry nor clearuseSystemBucket. The app's HelmRelease is left failing until an operator manually flipsbackup.useSystemBucketoff.Flagged by IvanHunters during review of #3313 (#3313 (review)); it is pre-existing on
main(both the guard and the patch shape predate that PR's merge-base), so it was split out rather than fixed there.Evidence
packages/apps/postgres/templates/db.yaml):{{- if and .Values.bootstrap.enabled .Values.backup.useSystemBucket }}{{- fail "postgres: bootstrap.enabled=true is incompatible with backup.useSystemBucket=true. Use a backups.cozystack.io/RestoreJob against the cozy-default BackupClass to restore from the system bucket; ..." }}— note the message recommends exactly the RestoreJob path that then trips this guard.internal/backupcontroller/postgresapp/types.go):PostgresSpec.Backuphas nouseSystemBucketfield ("Add new fields here only when the driver genuinely needs them; everything else stays on the server, untouched by the controller's patches"), so the restore patch leaves the liveuseSystemBucket: truein place while settingbootstrap.enabled: trueand the legacy restore coordinates.bootstrap.enabled: truewithuseSystemBucket: true, the chart render fails, and the HelmRelease (remediation retries -1) loops on the same render error forever — the restore never completes and the guard's own error message is what the operator sees.Impact
useSystemBucket: truePostgres in place (RestoreJob targeting the same release) wedges the release. Restore into a fresh release name works only if the new app is created withoutuseSystemBucket.Proposed fix (pick one)
useSystemBucketto the driver's partial app schema and have the restore patch explicitly set it tofalse(the restore patch already supplies the full legacy coordinates, so the semantics stay consistent), restoring it after the bootstrap completes if desired; orbootstrap.enabled && useSystemBucketwhen the restore coordinates are fully supplied (the guard exists to catch missing coordinates, not the driver-managed restore); orbootstrapand re-assertuseSystemBucketas part of restore finalization, making the combination transient by construction.