admin/felhom-agent
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

reconcile: tier-aware restore-task deadline (S4.1 unattended offsite restore-test)

Browse Source 
A WAN (pbs-tier) restore of a large guest exceeds the restore-task wait's 10m
default → the wait expired mid-restore, teardown fired against a still-restoring
(not-yet-pool-associated) scratch guest → leak + a phantom VM.Allocate 403.

- RestoreTestSpec.RestoreTaskTimeout (0→10m default); the restore WaitTask passes
  it. Local tier unchanged (10m).
- config RestoreTestPBSRestoreTimeoutSeconds + accessor (default 120m).
- main restoreTaskTimeout(cfg,tier): configured PBS timeout only when tier==pbs,
  else 0. Both scheduler + selftest spec builds.
- Tests + WaitOptions red-proof + accessor contract.

The "grant scratch-band VM.Allocate" follow-up is diagnosed not blind-applied:
the scratch is restored INTO /pool/felhom (ACL already grants VM.Allocate), so
the earlier 403 was a consequence of the timeout. No ACL/host-install change.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PSK5g6qYLknKj8u3QAFEr6
This commit is contained in:
authentik Default Admin
2026-07-04 19:45:26 +02:00
parent fee1fcfccd
commit dc70e15d28
7 changed files with 132 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CHANGELOG.md
+22
View File
@@ -1,3 +1,25 @@
## v0.68.0 — S4.1: tier-aware restore-task deadline (unattended offsite restore-test) (2026-07-04)
The offsite restore-test couldn't complete on the scheduler path because a WAN restore of a large
guest exceeds the restore-task wait's 10-minute default — the wait expired mid-restore, teardown
then fired against a still-restoring (not-yet-pool-associated) scratch guest, and it leaked. Make
the restore-task wait **tier-aware**.
- **`internal/reconcile`**: `RestoreTestSpec.RestoreTaskTimeout` (0 → the 10m `WaitOptions` default);
the restore-task `WaitTask` now passes it. Local-tier restores are UNCHANGED (10m — a local
restore hanging that long is a genuine fault).
- **`internal/config`**: `BackupConfig.RestoreTestPBSRestoreTimeoutSeconds` + accessor
`RestoreTestPBSRestoreTimeout()` (positive as-is, else **120m** — for an unattended nightly test a
false timeout is worse than a slow pass; very large guests may need more).
- **`cmd/felhom-agent`**: `restoreTaskTimeout(cfg, tier)` sets the field to the configured PBS
timeout only when `SourceTier=="pbs"` (both the scheduler + selftest spec builds), else 0.
- Tests: tier-aware `WaitOptions.Timeout` (pbs→120m, local→0; red-proofed against `WaitOptions{}`) +
the accessor contract. The "grant scratch-band `VM.Allocate`" follow-up was diagnosed, not
blind-applied — the scratch guest is restored INTO `/pool/felhom` (whose ACL already grants
`VM.Allocate`), so the earlier teardown 403 was a *consequence* of the timeout (a not-yet-pooled,
still-restoring guest), not a missing grant. **No ACL/host-install change.** (Live confirmation of
the phantom in REPORT.)
## v0.67.0 — S4: namespace-aware PBS client (per-customer offsite tenancy) (2026-07-04)
Phase-1 live probe on felhom-hetzner proved the offsite tenancy path (backup/restore/list/isolation