chore(velero): script the demo cluster so the fixtures outlive the session

[nadaverell]

The Velero fixtures from RAD-314 existed only in one throwaway kind cluster. gitops-demo and crossplane-demo already solve this for their integrations, and CLAUDE.md gives the reason: without a demo cluster you test against whatever context happens to be current, which is usually a real cluster missing exactly the variety that matters. Velero had the same problem and no answer.

make velero-demo          # ~2 min, offline after the chart pull
make velero-demo-status   # inventory
make velero-demo-verify   # re-assert without reapplying
make velero-demo-down

The payload is the states you can't get by installing Velero

Anyone can helm install velero. What took the time was everything below.

All 13 Backup phases, including the eight that must stay silent in Issues. A phase that starts raising is the regression this file exists to catch — silence here is coverage, not its absence.

The supersession series — a later success clearing an earlier failure within one schedule, plus an ad-hoc failure that must never be cleared. Three separate files applied with a pause, because ordering is by creationTimestamp and the API server assigns it: same-second creation decides ordering by the name tie-break instead of by time, and the test then passes for a reason unrelated to what it checks. verify asserts the timestamps are distinct and correctly ordered.

The paused-AND-invalid Schedule, and a schedule rejected for a missing storage location while its cron is valid — the counter-example that stops anyone deriving "invalid cron" from the status and reddening the wrong cell.

A restic BackupRepository, and two distinct repository statuses, since a column holding one distinct value renders no filter control at all and can't exercise the filter.

The real rancher/backup-restore-operator CRD, vendored rather than mocked, because the guard under test is "select on the API group, not the plural" and a mock proves much less.

Two gotchas stated up front, both found the slow way

• The controller is scaled to 0 on purpose. The failure phases need real object storage; a live controller with no bucket produces exactly one outcome — everything Failed on credentials, the least interesting row in the table.
• A plain kubectl apply writes status here. None of the six Velero CRDs declare a status subresource, so the familiar "apply drops status" rule doesn't apply, and kubectl patch --subresource=status fails against them with a confusing NotFound. I built the patching layer first and deleted it.

Fixtures store @now±Nm tokens rather than absolute dates, so the demo doesn't age into "expired 8 months ago" and leave the Expires / Last Backup / Age columns demoing nothing.

Deliberately not covered

Anything needing a live controller — data mover (DataUpload/DataDownload, wanted by RAD-316), real progress counters, and per-item error detail, which lives in an object-storage artifact behind a DownloadRequest. RAD-316 would need MinIO and a snapshot-capable CSI driver and the node agent and a workload with a bound PVC: a different and much more fragile fixture, not a flag on this one. Hand-faking DataUpload CRs would test our renderer against our own guess at the shape, and the shape is the thing in doubt. The README says so rather than pretending.

Testing

velero-demo.sh reset from nothing, then Radar pointed at the result: 14 issues, matching the hand-built cluster exactly — 12 backup_failed, 2 backup_target_unavailable. The superseded backup is absent, the ad-hoc failure present, and all eight silent phases silent. The five in-script assertions pass. Also bash -n clean, and the script is idempotent (re-run against an existing cluster reuses it).

---

Note

Low Risk
Dev-only scripts and fixtures; no production app, auth, or runtime behavior changes.

Overview
Adds a Velero demo bootstrap parallel to crossplane-demo / gitops-demo: make velero-demo (plus down, status, verify) drives scripts/velero-demo.sh, which creates a kind cluster, installs pinned Velero 1.18.1 via Helm, scales the controller to 0, and applies YAML fixtures with @now±Nm timestamps expanded at apply time.

The fixtures encode states that are hard to get on kind without real object storage: all 13 Backup phases (including phases that must stay silent in Issues), supersession (failed then completed nightly backups plus a non-superseded ad-hoc failure), varied Schedules (paused+invalid, errors with no phase), Unavailable BSL, restic and multi-status BackupRepositories, restores across phases, and the Rancher restores.resources.cattle.io plural collision via a vendored CRD + sample CR.

verify re-asserts controller absence, phase coverage, supersession creationTimestamp ordering, collision CR, and restic repo without reapplying. Documentation in scripts/velero-demo/README.md explains the scaled-to-zero trick, status-on-apply behavior, coverage matrix, and explicit limits (no live controller / data mover / real buckets).

^{Reviewed by Cursor Bugbot for commit 60f24ee. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 650fac3. Configure here.}

[nadaverell]

Closing in favor of the consolidated scope in #1402. After review, the synthetic Velero harness is intentionally not being added to the shared codebase; this branch remains intact as an archived fixture harness if it is useful later.