You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit a89321f
Browse filesBrowse the repository at this point in the historyBrowse files
fix(mongodb): keep retentionPolicy a genuine no-op, and cancel a timed-out backup so it cannot orphan an archive
Every prose surface (the useSystemBucket field, the retentionPolicy field, and
backup-classes.md) tells a tenant that schedule and retentionPolicy are ignored
on this flow, and cozyvalues-gen copies that into the schema, README and the
dashboard. A render-time reject of a non-default retentionPolicy contradicted
all of them: a tenant who followed the documented opt-in with a retentionPolicy
still set got a failed render and a HelmRelease that stopped converging, pointed
at the very doc that says the field does nothing. Drop the reject so
retentionPolicy is inert exactly as documented, handled the same way as schedule
(gated out, no error). The absence of retention on this flow is real but belongs
to a follow-up, so the docs now point at the BackupRetentionPolicy design (#4192)
and the teardown-GC issue (#3966), and recommend an S3 lifecycle policy until
they land.
Cancel a timed-out operator backup instead of only failing the BackupJob. The
deadline fires for a backup the operator has not begun streaming; but `waiting`
is the state pbm reports for a backup queued behind another, and the operator
starts it once the slot frees — after the BackupJob is Failed and never
reconciled again, writing an archive into the shared bucket that no Backup
object represents. The deadline branch now deletes the operator CR before
failing, which prevents that late run entirely: at v1.22.0 the operator returns
for a CR with a deletion timestamp before it dispatches to pbm, so nothing is
written. The delete is best-effort so it never blocks the failure.
Assisted-By: LLM
Signed-off-by: Andrey Kolkov <[email protected]>
Copy file name to clipboardExpand all lines: docs/operations/backup-classes.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -121,7 +121,7 @@ When `useSystemBucket: true`:
121
121
122
122
Because the chart drops `spec.backup.tasks` and `spec.backup.pitr`, the psmdb operator's own scheduled backups and oplog PITR do **not** run on this flow — `backup.schedule` and `backup.retentionPolicy` stay in the schema for the default flow but have no effect here, and the `recoveryTime` PITR restores described below are not available. Migrate scheduled backups to a `backups.cozystack.io/Plan` against `cozy-default` instead. **Flipping this flag on a running app** removes the storage, tasks and pitr the app had, so a release that was taking scheduled backups + PITR before the flip stops until a `Plan` takes over.
123
123
124
-
Dropping `spec.backup.tasks` also drops the psmdb `keep` retention it carried, so on this flow **the driver owns the archive** the way the Rabbitmq/Redis drivers own theirs (an on-demand `PerconaServerMongoDBBackup` is not covered by psmdb task retention). The driver stamps the operator's `percona.com/delete-backup` finalizer onto each backup it mints here, and deleting a Cozystack `Backup` (a retention-pruned `Plan`, or a manual delete) deletes that `PerconaServerMongoDBBackup` CR — whose finalizer removes the pbm object from the shared bucket before the `Backup` is released, so a Plan does not accumulate objects in `cozy-backups`. A legacy backup writes to the tenant's own bucket and keeps the pre-existing hands-off contract (its lifecycle stays the tenant's / operator's; nothing is deleted on `Backup` removal). Note this prunes only when a `Backup` is deleted: unlike CNPG and MariaDB, which prune engine-side on their own schedule, MongoDB has no engine-side scheduled trim on this flow, so keeping `cozy-backups` bounded depends on a `Plan`'s retention actually deleting old `Backup` objects (scheduled retention at the `Plan` level is tracked as future work). Two cases release the `Backup` without waiting for the object to be pruned, so a wedged prune never pins a namespace in `Terminating`: a terminating namespace (where the operator's delete-backup step cannot run) and the `backups.cozystack.io/skip-artifact-cleanup: "true"` annotation. In both the driver strips its own finalizer and leaves the object for a bucket lifecycle policy to reclaim. A down operator or unreachable storage in a live namespace is NOT released automatically — the `Backup` stays `Terminating` as a visible signal until the operator recovers or you set that annotation to force the release.
124
+
Dropping `spec.backup.tasks` also drops the psmdb `keep` retention it carried, so on this flow **the driver owns the archive** the way the Rabbitmq/Redis drivers own theirs (an on-demand `PerconaServerMongoDBBackup` is not covered by psmdb task retention). The driver stamps the operator's `percona.com/delete-backup` finalizer onto each backup it mints here, and deleting a Cozystack `Backup` (a retention-pruned `Plan`, or a manual delete) deletes that `PerconaServerMongoDBBackup` CR — whose finalizer removes the pbm object from the shared bucket before the `Backup` is released, so a Plan does not accumulate objects in `cozy-backups`. A legacy backup writes to the tenant's own bucket and keeps the pre-existing hands-off contract (its lifecycle stays the tenant's / operator's; nothing is deleted on `Backup` removal). Note this prunes only when a `Backup` is deleted: unlike CNPG and MariaDB, which prune engine-side on their own schedule, MongoDB has no engine-side scheduled trim on this flow, so keeping `cozy-backups` bounded depends on a `Plan`'s retention actually deleting old `Backup` objects. **A `Plan` has no retention field yet** (`PlanSpec` carries only `applicationRef`, `backupClassName` and `schedule`), so today a nightly `useSystemBucket` Plan grows the shared bucket unbounded — `schedule` and `retentionPolicy` on the app are inert here (see [MongoDB: opt-in to the system bucket](#mongodb-backup-storage)), and platform-level retention is tracked in the [`BackupRetentionPolicy` design (#4192)](https://github.com/cozystack/cozystack/pull/4192). Teardown GC of orphaned `Backup`s / S3 data is [#3966](https://github.com/cozystack/cozystack/issues/3966). Until those land, bound `cozy-backups` with an S3 lifecycle policy on the object store. Two cases release the `Backup` without waiting for the object to be pruned, so a wedged prune never pins a namespace in `Terminating`: a terminating namespace (where the operator's delete-backup step cannot run) and the `backups.cozystack.io/skip-artifact-cleanup: "true"` annotation. In both the driver strips its own finalizer and leaves the object for a bucket lifecycle policy to reclaim. A down operator or unreachable storage in a live namespace is NOT released automatically — the `Backup` stays `Terminating` as a visible signal until the operator recovers or you set that annotation to force the release.
125
125
126
126
**Opting back out** (`useSystemBucket` true→false) is not automatic in reverse: the driver stops injecting, but the `s3-storage` entry it already applied stays on the live `PerconaServerMongoDB` under the driver's own field manager (`cozystack-psmdb-backup-driver`) — the chart does not own it and so never prunes it. It is inert once `backup.enabled=false`; to fully return a release to the legacy flow, delete that storage entry from the `PerconaServerMongoDB` by hand before re-declaring the tenant's own `backup.*` S3 values.
Copy file name to clipboardExpand all lines: packages/apps/mongodb/templates/mongodb.yaml
-12Lines changed: 0 additions & 12 deletions
Original file line number
Diff line number
Diff line change
@@ -217,18 +217,6 @@ spec:
217
217
{{- end }}
218
218
{{- end }}
219
219
220
-
{{- /*
221
-
useSystemBucket cannot honour backup.retentionPolicy: the tasks[].keep block
222
-
below (the chart's only retention) is gated out on this flow, and no
223
-
Plan-level retention exists yet, so a retentionPolicy set here would silently
224
-
grow the shared cozy-backups bucket. Reject a value the tenant changed from
225
-
the chart default rather than ignore it — an untouched useSystemBucket install
226
-
keeps rendering. $defaultRetentionPolicy MUST track the values.yaml default.
227
-
*/}}
228
-
{{- $defaultRetentionPolicy := "30d" }}
229
-
{{- if and .Values.backup.useSystemBucket .Values.backup.retentionPolicy (ne .Values.backup.retentionPolicy $defaultRetentionPolicy) }}
230
-
{{- fail (printf "backup.retentionPolicy=%q cannot be honoured when backup.useSystemBucket=true: the platform flow has no engine-side retention and Plan-level retention is not yet available (see docs/operations/backup-classes.md). Remove backup.retentionPolicy, or drive scheduled backups and retention through a backups.cozystack.io/Plan." .Values.backup.retentionPolicy) }}
Copy file name to clipboardExpand all lines: packages/apps/mongodb/tests/mongodb_test.yaml
+8-21Lines changed: 8 additions & 21 deletions
Original file line number
Diff line number
Diff line change
@@ -93,10 +93,10 @@ tests:
93
93
path: spec.backup.pitr
94
94
documentIndex: 0
95
95
96
-
- it: rejects a non-default retentionPolicy on useSystemBucket
97
-
#The platform flow cannot honour retentionPolicy (no engine-side trim, no
98
-
#Plan retention yet), so a value the tenant changed from the default is a
99
-
#hard error rather than a silent no-op that grows the shared bucket.
96
+
- it: ignores retentionPolicy and schedule on useSystemBucket (renders, no tasks)
97
+
#On this flow retentionPolicy and schedule are inert (documented as ignored),
98
+
#handled the same way: a custom value renders cleanly without emitting the
99
+
#tasks block, never a hard render error.
100
100
release:
101
101
name: test-mongodb
102
102
namespace: tenant-test
@@ -107,28 +107,15 @@ tests:
107
107
enabled: true
108
108
useSystemBucket: true
109
109
retentionPolicy: 7d
110
-
asserts:
111
-
- failedTemplate:
112
-
errorMessage: 'backup.retentionPolicy="7d" cannot be honoured when backup.useSystemBucket=true: the platform flow has no engine-side retention and Plan-level retention is not yet available (see docs/operations/backup-classes.md). Remove backup.retentionPolicy, or drive scheduled backups and retention through a backups.cozystack.io/Plan.'
113
-
114
-
- it: allows the default retentionPolicy on useSystemBucket
115
-
# The untouched default must still render, so the guard only fires on a
116
-
# tenant-changed value (this pins the discriminator, not just the reject).
0 commit comments