mitchell/hamlab
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 14 Wiki Activity

PLAN: schedules are cron jobs, and zfSnap is retired

Browse Source 
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Mitchell-Johnson
2026-09-24 13:12:17 -07:00
co-authored by Claude Opus 5
parent 09b7558d44
commit c3854bafda
1 changed files with 18 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
PLAN.md
+18 -2
View File
@@ -296,8 +296,24 @@ something long in one, switch away and back, refresh — it's all still there.
**Nothing is destroyed unseen.** Every schedule answers *what would it delete?* with the **Nothing is destroyed unseen.** Every schedule answers *what would it delete?* with the
list, sizes and dates, before Run now touches anything; only names that parse as a stamp list, sizes and dates, before Run now touches anything; only names that parse as a stamp
and a TTL are candidates, so a snapshot taken by hand is invisible to it; and a snapshot and a TTL are candidates, so a snapshot taken by hand is invisible to it; and a snapshot
deleted by hand needs its full name typed back. The scheduler is a 30 s tick in the daemon, deleted by hand needs its full name typed back.
and `Run now` calls the same code, so the button and the timer cannot drift apart. **A schedule is a real cron job** (2026-09-24, Mitchell's call after the first cut ran it
from a ticker inside the daemon). Ham Lab writes `/etc/cron.d/hamlab-zfs`, owns it, and
rewrites it whole on every change; each line calls `hamlab zfs-snapshot <id>` as the
account Ham Lab runs as, reaching zfs through sudo as the daemon does. Snapshots are
backup-shaped and must not stop because a console is down, upgrading, or uninstalled — and
a cron line is greppable by anyone looking at the machine the normal way. **A cron
expression is the single description of when a schedule fires**: the four common shapes
render to one, `custom` states one outright, and the next run is read back with the same
evaluator the Jobs tab uses on everyone else's lines, so the page, the file and the
prediction cannot disagree. A run's outcome is written to `zfs-runs/<id>.json` beside the
config, never to `state.json`, because the cron job is a separate process and the daemon
would clobber it. An existing external job can be **adopted** — its schedule, retention
and dataset read out of the cron line into a new Ham Lab schedule.
**zfSnap is retired on `grid`** as of that day: Ham Lab now takes the nightly `tank`
snapshot, the package is purged and the old cron line is gone, with the 515 snapshots it
had taken left untouched and fully readable here — which is what adopting its naming
bought. See `hamlet/docs/hosts.md`.
- **Skins** — 13 since 2026-09-19 (`themes.ts`: a palette is one `mk(…)` line): Dark, - **Skins** — 13 since 2026-09-19 (`themes.ts`: a palette is one `mk(…)` line): Dark,
Light, Cyberpunk, Retro, **HUD** (hairlines of cyan on near-black, corner ticks, thin Light, Cyberpunk, Retro, **HUD** (hairlines of cyan on near-black, corner ticks, thin
type), Nord, Gruvbox, Catppuccin + Latte, Dracula, Tokyo Night, Solarized Dark + Light; type), Nord, Gruvbox, Catppuccin + Latte, Dracula, Tokyo Night, Solarized Dark + Light;