fix(backup): simplify UX with default backupclass and correct the admin override path (next + v1.5)#622
fix(backup): simplify UX with default backupclass and correct the admin override path (next + v1.5)#622Andrey Kolkov (androndo) wants to merge 9 commits into
Conversation
✅ Deploy Preview for cozystack ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe documentation introduces the platform-managed ChangesPlatform-managed BackupClass model
Tenant database backup workflow
Virtualization backup workflow
Application backup cross-references
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related issues
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Code Review
This pull request consolidates backup configuration documentation by introducing a unified BackupClass (cozy-default) for both managed databases and VM backups, replacing previous per-application configurations. The changes update various documentation files to reflect this centralization and provide instructions for platform-managed storage. The review feedback provides actionable suggestions to improve documentation navigation, fix command syntax in examples, and clarify phrasing regarding versioning.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@content/en/docs/next/operations/services/backup-classes.md`:
- Around line 167-169: Update the external S3 instructions in both
content/en/docs/next/operations/services/backup-classes.md lines 167-169 and
content/en/docs/v1.4/operations/services/backup-classes.md lines 167-169 to
configure provisionBucket through
spec.components.platform.values.backupStorage.provisionBucket: false instead of
editing backupstrategy-controller values directly; leave the remaining
credential and endpoint guidance unchanged.
- Line 96: Replace the malformed BSL readiness checks with valid kubectl wait
--for=jsonpath='{.status.phase}'=Available syntax in
content/en/docs/next/operations/services/backup-classes.md:96,
content/en/docs/v1.4/operations/services/backup-classes.md:96,
content/en/docs/next/virtualization/backup-and-recovery.md:45, and
content/en/docs/v1.4/virtualization/backup-and-recovery.md:45. Apply the same
correction to each cozy-default readiness check.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: e89c8e55-8532-4ee6-b03d-59ea2ec99de1
📒 Files selected for processing (17)
content/en/docs/next/applications/backup-and-recovery.mdcontent/en/docs/next/applications/clickhouse.mdcontent/en/docs/next/applications/mariadb.mdcontent/en/docs/next/applications/postgres.mdcontent/en/docs/next/kubernetes/backups-with-velero-addon.mdcontent/en/docs/next/operations/configuration/platform-package.mdcontent/en/docs/next/operations/services/backup-classes.mdcontent/en/docs/next/operations/services/managed-app-backup-configuration.mdcontent/en/docs/next/operations/services/velero-backup-configuration.mdcontent/en/docs/next/virtualization/backup-and-recovery.mdcontent/en/docs/v1.4/applications/backup-and-recovery.mdcontent/en/docs/v1.4/kubernetes/backups-with-velero-addon.mdcontent/en/docs/v1.4/operations/configuration/platform-package.mdcontent/en/docs/v1.4/operations/services/backup-classes.mdcontent/en/docs/v1.4/operations/services/managed-app-backup-configuration.mdcontent/en/docs/v1.4/operations/services/velero-backup-configuration.mdcontent/en/docs/v1.4/virtualization/backup-and-recovery.md
💤 Files with no reviewable changes (4)
- content/en/docs/v1.4/operations/services/managed-app-backup-configuration.md
- content/en/docs/v1.4/operations/services/velero-backup-configuration.md
- content/en/docs/next/operations/services/velero-backup-configuration.md
- content/en/docs/next/operations/services/managed-app-backup-configuration.md
IvanHunters
left a comment
There was a problem hiding this comment.
Verdict
NOT LGTM
The next/ half is accurate and matches cozystack/cozystack#3333, but the v1.4/ half documents a feature that release-1.4 does not ship, and the version that actually ships it (v1.5, docs already cut in this repo) is not updated at all.
Findings
[CRITICAL] content/en/docs/v1.4/** — the v1.4 rewrite documents the cozy-default BackupClass, which does not exist in release-1.4
Verified against the cozystack repo: on branch release-1.4, packages/system/backupstrategy-controller/templates/ contains only crds.yaml, deployment.yaml, rbac.yaml, rbac-bind.yaml, sa.yaml — no backupclass-default.yaml, no bucket.yaml, no velero-bsl.yaml, no strategy-*-default.yaml — and its values.yaml has no backupStorage block. The 1.4 release announcement (this repo, content/en/blog/2026-05-21-...) likewise describes the manual strategy/BackupClass flow. The entire feature ships in release-1.5 (backupclass-default.yaml etc. confirmed on branch release-1.5; the 1.5 announcement says "A platform-managed BackupClass named cozy-default is now shipped by default"). The PR body's stated assumption — that a cozystack/cozystack#3333 backport to release-1.4 makes the v1.4 copies valid — is insufficient: #3333 only forwards backupStorage values into the child Package; on release-1.4 the receiving chart has nothing to consume them. A 1.4 operator following the new v1.4/operations/services/backup-classes.md (and the new backupStorage row in v1.4/operations/configuration/platform-package.md:110-115) will set an override that silently does nothing and will believe tenants have working default backups; meanwhile the PR deletes the only correct 1.4 guides (managed-app-backup-configuration.md, velero-backup-configuration.md). Fix: drop the v1.4/ changes from this PR entirely, or gate them on an actual full feature backport (which is not just #3333).
[MAJOR] content/en/docs/v1.5/** (untouched) — the version that ships cozy-default keeps the obsolete guides this PR deletes elsewhere
content/en/docs/v1.5/ exists in the tree (cut with the 2026-06-28 release; the PR-body premise "release-1.5 when its docs version is cut" is stale). It still contains operations/services/managed-app-backup-configuration.md and velero-backup-configuration.md, and v1.5/applications/backup-and-recovery.md still instructs tenants to use per-app class names and admin-provisioned credential Secrets — while v1.5/applications/postgres.md:39-41 already documents backup.useSystemBucket + cozy-default, so v1.5 docs are now internally contradictory. This also breaks the PR-body claim "covering all documentation versions 1.4+", and CONTRIBUTING.md:41 requires a change applying to multiple versions to be copied to each. The correct target set for this rewrite is next/ + v1.5/, not next/ + v1.4/.
[MAJOR] content/en/docs/{next,v1.4}/operations/services/backup-classes.md:1-5 — deleted pages leave published permalinks 404 with no aliases
The 1.4 release announcement links to https://cozystack.io/docs/v1.4/operations/services/managed-app-backup-configuration/ twice (content/en/blog/2026-05-21-cozystack-1-4-.../index.md:86,196); these are absolute URLs, so the Hugo build stays green while the published links start 404ing the moment this merges. The same trap will apply on a v1.5 retarget: the 1.5 announcement links to the v1.5 copy (content/en/blog/2026-06-28-cozystack-1-5-.../index.md:214). Whichever released version ends up losing pages, add aliases: frontmatter on the replacing backup-classes.md covering both old URLs (.../managed-app-backup-configuration/, .../velero-backup-configuration/).
[MINOR] content/en/docs/next/applications/backup-and-recovery.md:8 (and the v1.4 copy) — intro and troubleshooting not updated for Etcd
The prerequisites and examples now include Etcd as a supported Kind, but the opening sentence still reads "Postgres, MariaDB, and ClickHouse", and the escalation paragraph (next/applications/backup-and-recovery.md:203) still enumerates only cnpg.io/Backup, k8s.mariadb.com/Backup, and ClickHouse Pod logs — no Etcd driver diagnostic.
[MINOR] content/en/docs/next/applications/backup-and-recovery.md:207-209 (and the v1.4 copy) — duplicate "See also" bullet
Two bullets both titled "[Backup Classes]" link to the same page with different descriptions (one inherited from the deleted Velero page). Merge into a single bullet.
Caveats
- Phase 5b (existing-customer upgrade / fresh-install impact) is classified N/A: this PR is docs-only in the website repo and touches nothing under
packages/; there is no chart, migration, RBAC, or image surface to analyse. - cozystack/cozystack#3333 is still OPEN as of this review (checked 2026-07-17). The PR body correctly orders this PR after it; the maintainer must enforce that ordering at merge time — until #3333 lands, the documented override path does not work on
maineither. - The documented override path was verified against the actual fix, not taken on trust:
spec.components.platform.values.backupStorageand the "forwarded into the childPackage cozystack.backupstrategy-controller" description match #3333's diff exactly (packages/core/platform/templates/bundles/system.yamlforwarding block plus the same correction in the cozystack repo's owndocs/operations/backup-classes.md, which also names the two non-working paths). No stale references to the oldspec.components.backupstrategy-controllerpath remain innext/orv1.4/. - Dead-link sweep: no remaining
{{% ref %}}references to the two deleted pages exist insidenext/orv1.4/; all remaining in-tree references live in other versions (v1.0–v1.3,v1.5) pointing at their own still-present copies, so Hugo ref resolution is unaffected. The two newbackup-classes.mdfiles are byte-identical (same blob) and contain no version-scoped{{% ref %}}shortcodes, so the duplication does not cross-link versions. - Technical content of the new page (strategy CR names,
backupStorageknobs, projected-Secret key formats) was spot-checked against the release-1.5backupstrategy-controllerchart (values.yamlcomments, templates listing) and is consistent; I did not independently verify every knob row (e.g.bucketNameOverride, the per-driver endpoint-shape table) against chart template internals.
Recommended follow-ups
- Port the
v1.4/half of this PR tocontent/en/docs/v1.5/(same two-commit structure applies cleanly; v1.5 is where the feature actually ships). - Consider a repo convention (or CI check) requiring
aliases:frontmatter whenever a page is deleted from a released docs version, since absolute blog links bypass Hugo's ref checking.
…and backupclass (next + v1.5) Retarget of the released-version half of the original commit from cherry-pick c1a3ff8 (PR #547): the cozy-default BackupClass feature ships in release-1.5, not release-1.4, so the rewritten guides land in content/en/docs/v1.5/ instead of v1.4/. The v1.5 base pages were identical to the v1.4 ones modulo version refs, so the port is the same content with /docs/v1.5/ refs. Signed-off-by: Andrey Kolkov <androndo@gmail.com>
…review findings (next + v1.5) The admin-override example documented a path the cozystack operator silently ignores (cozystack/cozystack#3245): that PackageSource exposes only the platform component. cozystack/cozystack#3333 wires the working path — spec.components.platform.values.backupStorage — which the platform chart forwards into the backupstrategy-controller component. Update the example in both next/ and v1.5/, explain the forwarding, call out the two plausible-looking paths that do not work, use the same platform Package path in the external-S3 section, and add the new backupStorage key to the platform-package values reference tables. Review fixes from PR #622 (IvanHunters, gemini, coderabbit): - add aliases frontmatter on backup-classes.md for the two deleted pages, so published permalinks (release announcements link them as absolute URLs) keep resolving - replace the malformed BSL readiness check (jsonpath '=' 'Available' passed as extra kubectl args) with kubectl wait --for=jsonpath='{.status.phase}'=Available, and rephrase the tenant-facing variant to 'returns Available' - namespace the flux reconcile example (-n cozy-backup-controller, the namespace the backupstrategy-controller HelmRelease actually lives in per packages/core/platform/sources/backupstrategy-controller.yaml) - link the FoundationDB caveat section instead of quoting its title - 'After v1.4' -> 'Starting with v1.4' in the upgrade note - mention Etcd in the tenant guide intro/description and add etcd.aenix.io/EtcdBackup to the escalation diagnostics list - merge the duplicated Backup Classes bullet in See also Assisted-By: Claude <noreply@anthropic.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Andrey Kolkov <androndo@gmail.com>
cb94b51 to
8d39146
Compare
|
IvanHunters thanks — the CRITICAL finding is confirmed and addressed. Verified against the cozystack repo:
Bot findings addressed in the same commit: On merge ordering: the PR body now states the v1.5 half depends on a cozystack/cozystack#3333 backport to release-1.5 (the feature ships there, only the values forwarding is missing); #3333 carries the |
VerdictNOT LGTM The force-push resolves every prior-round finding (v1.4 no longer touched, v1.5 rewritten coherently, Findings[MAJOR] The note says "The pre-v1.4 defaults ... were the literal [MINOR] The escalation diagnostics list names [MINOR] PR title — still says "(next + v1.4)" while the diff, commits, and body are next + v1.5 The body and both commit subjects were updated to "(next + v1.5)", but the PR title (which becomes the squash-merge subject) still claims v1.4 coverage. Retitle to "(next + v1.5)". Caveats
Recommended follow-ups
|
…5, use EtcdSnapshot for next Review round 2 on PR #622: release-1.4 packages/apps/postgres/values.yaml still ships the placeholder s3AccessKey/s3SecretKey defaults and has no useSystemBucket at all — the empty-string defaults land in release-1.5, so the upgrade note's version boundary moves from v1.4 to v1.5 in both copies. On main the etcd backup driver has moved from etcd.aenix.io EtcdBackup to etcd-operator.cozystack.io EtcdSnapshot, so the next/ escalation diagnostics name the new CR while the v1.5 copy keeps EtcdBackup. Assisted-By: Claude <noreply@anthropic.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Andrey Kolkov <androndo@gmail.com>
Same note as the website copy (cozystack/website#622 review round 2): name the explicit version boundary instead of 'pre-PR / After this PR', so the two documents cannot diverge — the empty-string defaults and useSystemBucket shipped in release-1.5. Assisted-By: Claude <noreply@anthropic.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Andrey Kolkov <androndo@gmail.com>
|
All three round-2 findings addressed in 4a1cb07:
The |
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@content/en/docs/next/operations/services/backup-classes.md`:
- Line 105: Update the bootstrap resource description in the strategy-template
paragraph to state that the strategy configuration is incomplete until the
BucketClaim status is populated, while explicitly preserving that the
cozy-default Velero BackupStorageLocation is already present. Do not imply that
only the Bucket CR and BackupClass exist; keep the later Flux re-render behavior
unchanged.
- Line 12: Update the description of the system-managed `cozy-backups` reference
in the `BackupClass` documentation to identify it as the
`apps.cozystack.io/Bucket` resource name, not the underlying S3 bucket name.
Keep the existing `tenant-root` namespace detail and align the wording with the
COSI-assigned bucket name behavior described elsewhere.
- Line 116: Update the alert expression in the backup monitoring documentation
to use the fully qualified exported metrics and valid range vectors: replace the
failures condition with
rate(cozystack_backup_credentials_projection_failures_total[5m]) > 0 and the
stale-success condition with
absent_over_time(cozystack_backup_credentials_projection_successes_total[10m]).
In `@content/en/docs/v1.5/operations/services/backup-classes.md`:
- Line 4: Update the page description metadata to state that administrators can
tune BackupClass parameters while tenants only select a BackupClass name,
aligning it with the documented tenant workflow.
- Line 12: Update the BackupClass documentation to identify cozy-backups as the
system-managed Kubernetes Bucket/release resource in the tenant-root namespace,
not as the actual S3 bucket name. Reference the later COSI documentation for the
assigned S3 bucket name and preserve the existing provisioning details.
- Line 88: Update the credentials Secret description to clarify that the
original system-managed Secret remains in tenant-root, while only copies are
projected into tenant and configured system namespaces. Preserve the existing
details about projection timing, refresh behavior, and Secret naming.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 6ef226b0-f5c1-4e1e-b066-02e80369ca86
📒 Files selected for processing (17)
content/en/docs/next/applications/backup-and-recovery.mdcontent/en/docs/next/applications/clickhouse.mdcontent/en/docs/next/applications/mariadb.mdcontent/en/docs/next/applications/postgres.mdcontent/en/docs/next/kubernetes/backups-with-velero-addon.mdcontent/en/docs/next/operations/configuration/platform-package.mdcontent/en/docs/next/operations/services/backup-classes.mdcontent/en/docs/next/operations/services/managed-app-backup-configuration.mdcontent/en/docs/next/operations/services/velero-backup-configuration.mdcontent/en/docs/next/virtualization/backup-and-recovery.mdcontent/en/docs/v1.5/applications/backup-and-recovery.mdcontent/en/docs/v1.5/kubernetes/backups-with-velero-addon.mdcontent/en/docs/v1.5/operations/configuration/platform-package.mdcontent/en/docs/v1.5/operations/services/backup-classes.mdcontent/en/docs/v1.5/operations/services/managed-app-backup-configuration.mdcontent/en/docs/v1.5/operations/services/velero-backup-configuration.mdcontent/en/docs/v1.5/virtualization/backup-and-recovery.md
💤 Files with no reviewable changes (4)
- content/en/docs/v1.5/operations/services/velero-backup-configuration.md
- content/en/docs/v1.5/operations/services/managed-app-backup-configuration.md
- content/en/docs/next/operations/services/velero-backup-configuration.md
- content/en/docs/next/operations/services/managed-app-backup-configuration.md
🚧 Files skipped from review as they are similar to previous changes (7)
- content/en/docs/next/kubernetes/backups-with-velero-addon.md
- content/en/docs/next/applications/mariadb.md
- content/en/docs/next/applications/postgres.md
- content/en/docs/next/applications/clickhouse.md
- content/en/docs/next/operations/configuration/platform-package.md
- content/en/docs/next/virtualization/backup-and-recovery.md
- content/en/docs/next/applications/backup-and-recovery.md
…main, fix external-S3 BSL claim Branch-review round 3 on PR #622: - next/ copy carried pre-derivation endpoint semantics: on cozystack main (e160a0dc8) the backupstrategy-controller.endpoint helper derives the endpoint from the COSI system-credentials Secret (forced https://) whenever provisionBucket: true, and backupStorage.endpoint is only the fallback for external S3 and offline renders. Port the corrected wording from the monorepo docs/operations/backup-classes.md into the next/ copy (intro, post-table paragraph, endpoint knob row). The v1.5/ copy keeps the direct-endpoint wording — release-1.5 has no endpoint helper — making this the second deliberate divergence between the copies after the Etcd CR name. - both copies claimed the external-S3 path needs the chart's Velero BSL settings updated inside backupStorage; no such settings exist there and the platform Package path cannot carry velero.* values. The BSL is rendered from the same backupStorage block, so no separate step is needed — say that instead. - add a See also section to both copies (tenant guides, platform-package reference); the page previously had no outbound links. Assisted-By: Claude <noreply@anthropic.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Andrey Kolkov <androndo@gmail.com>
…hrasing; document namespace knob and bslEnabled gap
Branch-review round 3 blockers (both copies):
- the alerting guidance used truncated metric names and a rate() call
without a range vector; spell out
cozystack_backup_credentials_projection_{failures,successes}_total
with proper windows
- the frontmatter description claimed tenants tune BackupClass
parameters; tenants only reference a class by name — parameter tuning
is admin-only via sibling classes
- the intro conflated the Bucket CR name cozy-backups with the real
S3 bucket name (COSI-assigned via BucketClaim.status.bucketName)
Non-blocking recommendations from the same review:
- add the backupStorage.namespace knob row (where the Bucket CR lands;
must be a tenant-* namespace per the cozy-lib RBAC helper)
- state explicitly that velero.bslEnabled is not carried by the
backupStorage override path
Assisted-By: Claude <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Andrey Kolkov <androndo@gmail.com>
… namespace knob and bslEnabled gap Keep the monorepo doc aligned with the website copy (cozystack/website#622 branch-review round 3): full cozystack_backup_credentials_projection_* metric names with range vectors in the alerting examples, the intro no longer conflates the Bucket CR name with the COSI-assigned S3 bucket name, the knob table gains the backupStorage.namespace row, and the external-S3 section states that the Velero BSL derives from the same backupStorage block while velero.bslEnabled is not carried by the override path. Assisted-By: Claude <noreply@anthropic.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Andrey Kolkov <androndo@gmail.com>
…-election phrasing Deep verification against the cozystack repo (branch-review round 4) found two factual errors and one simplification, in both copies: - the re-render interval is 5 minutes, set by the cozystack operator's helmrelease-interval flag (cmd/cozystack-operator/main.go), not a '10 minutes Flux standard interval' - the FoundationDB backup CR group is apps.foundationdb.org, not foundationdb.org (internal/backupcontroller/foundationdbtypes) - the projector's first synchronous round is gated on leader election, not literally on pod readiness; say so while keeping the practical timing guidance Assisted-By: Claude <noreply@anthropic.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Andrey Kolkov <androndo@gmail.com>
…ax, leader-election phrasing Same corrections as the website copy (cozystack/website#622 round 4): the re-render interval is 5m via the operator's helmrelease-interval flag (not a 10-minute Flux default), the FoundationDB backup CR group is apps.foundationdb.org, the BSL readiness check uses valid kubectl wait --for=jsonpath syntax, and the projector's first synchronous round is gated on leader election rather than pod readiness. Assisted-By: Claude <noreply@anthropic.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Andrey Kolkov <androndo@gmail.com>
… pin the override to the #3333 backport Branch-review round 5: release-1.5's strategy-foundationdb-default.yaml derives secure_connection from the endpoint scheme exactly like the MariaDB strategy does, so the endpoint knob row must name both (the page's own driver table already says 'derived secure flag' for FDB). And the v1.5 page documented the platform-Package override without saying that no shipped v1.5 patch carries the forwarding yet — state that it requires the cozystack/cozystack#3333 backport, so a v1.5.0-v1.5.2 admin is not handed the same silently-ignored block that #3245 was filed about. Assisted-By: Claude <noreply@anthropic.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Andrey Kolkov <androndo@gmail.com>
…the #3333 backport, mention RestoreJob projection Branch-review round 6: the v1.5 platform-package.md reference row documented backupStorage with no version caveat — a reader landing on the standalone table on v1.5.0-v1.5.2 would set a silently-ignored key, the exact trap #3245 describes; the row now points at the required cozystack/cozystack#3333 backport. Also credentials are projected for RestoreJob reconciles too (restorejob_controller.go), not only BackupJob — say so everywhere the projection timing is described. Assisted-By: Claude <noreply@anthropic.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Andrey Kolkov <androndo@gmail.com>
The projector runs from both the BackupJob and RestoreJob controllers (restorejob_controller.go), not only before BackupJobs — keep the monorepo doc aligned with the website copy (cozystack/website#622). Assisted-By: Claude <noreply@anthropic.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Andrey Kolkov <androndo@gmail.com>
Mirrors the monorepo fix from the cozystack/cozystack#3333 review: with provisionBucket: false the bucketName value is taken verbatim as the real S3 bucket name by every strategy CR and the Velero BSL (no COSI lookup, the Secret's bucketName key alone is not read by the strategies), so the external-S3 section now requires updating it and the knob table states the two-mode semantics. Same helper behavior verified on release-1.5 for the v1.5 copy. Assisted-By: Claude <noreply@anthropic.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Andrey Kolkov <androndo@gmail.com>
What this PR does
Supersedes #547 and #621, combining both into one PR based on
mainand covering the documentation versions that actually ship the feature:next/andv1.5/.Commit 1 (retarget of #547): simplify the backup guides around the platform-provided default strategies and the
cozy-defaultBackupClass — a new Backup Classes admin page replacesmanaged-app-backup-configuration.mdandvelero-backup-configuration.md, and the applications / virtualization / velero-addon guides are rewritten aroundbackupClassName: cozy-default. Applied tonext/and ported tov1.5/(the v1.5 base pages were identical to the v1.4 ones modulo version refs).v1.4/is untouched: release-1.4 does not shipcozy-default(packages/system/backupstrategy-controllerthere has no default BackupClass/strategy templates and nobackupStoragevalues block), so the v1.4 guides for the manual flow remain correct as they are.Commit 2 (override path + review findings, both versions): the admin-override example documented a path the cozystack operator silently ignores —
spec.components.backupstrategy-controller.valueson thePackage cozystack.cozystack-platform(cozystack/cozystack#3245). cozystack/cozystack#3333 wires the working path:spec.components.platform.values.backupStorage. Innext/andv1.5/:operations/services/backup-classes.md— the override example usescomponents.platform.values.backupStorage, a paragraph explains the forwarding and calls out the two plausible-looking paths that do not work; the external-S3 section uses the same platform Package path;aliases:frontmatter keeps the deleted pages' permalinks resolving (the release announcements link them as absolute URLs, which Hugo's ref checking cannot see).operations/configuration/platform-package.md— thespec.components.platform.values.*reference table gains the newbackupStoragekey.kubectl wait --for=jsonpath='{.status.phase}'=Availablereadiness checks instead of the malformed= Availabletail,flux reconcile helmrelease backupstrategy-controller -n cozy-backup-controller(the namespace the HelmRelease actually lives in — notcozy-system), anchor link for the FoundationDB caveat, "Starting with v1.4" phrasing, Etcd mentioned in the tenant guide intro and escalation diagnostics (etcd.aenix.io/EtcdBackup), merged duplicate "See also" bullet.Merge ordering
maineither.v1.5/half additionally assumes fix(platform): forward backupStorage overrides to the backupstrategy-controller Package cozystack#3333 is backported to release-1.5 (the feature ships there; only the values forwarding is missing). #3333 carries thebackportlabel for this.Summary by CodeRabbit
cozy-defaultBackupClass, including supported drivers (now including Etcd), credential projection behavior, troubleshooting, and observability/alerting guidance.backupStorage) configuration block forcozy-default.cozy-defaultand the unified Backup Classes documentation.