feat(svos): v0.0.18 live on nh3-svos — interface 0.0.7 (U20 settings) + UI 0.0.22; card approved 2352:16; kernel process left on identical 0.0.17 code

2026-10-18 23:52:56 -07:00
parent 16603fe70b
commit f281bfb830
2 changed files with 23 additions and 2 deletions
@@ -23,6 +23,27 @@ configuration, enrollment and acceptance.
 | App-consistent hook | svos-dev's `/etc/qemu/fsfreeze-hook.d/50-svos` stops the SVOS services on freeze and restarts the ones that were running on thaw. ⚠ **Debian's qemu-ga does NOT run fsfreeze hooks unless configured** (no `-F` in the unit, no `qemu-ga.conf` by default). Here `/etc/qemu/qemu-ga.conf` points it at **`/usr/local/sbin/fsfreeze-dispatch`** (`configs/qemu-ga/fsfreeze-dispatch`), which unlike the stock `/etc/qemu/fsfreeze-hook` propagates failure: if a freeze hook fails, it thaws that hook and the completed ones and exits 1, so qemu-ga refuses the freeze. **Live drill 2026-10-05 1952–1953 (services running):** quiesced backup `vm/111/2026-10-06T02:52:11Z` → kernel+interface down ~1–2 s, back by themselves, health ok. Refused freeze (temporary `60-drill-refuse` after 50-svos, since removed) `vm/111/2026-10-06T02:53:03Z` → the dispatcher unwound and restarted the services, and then **⚠ vzdump did NOT abort: it logged `ERROR: unable to freeze guest fs`, backed up UNFROZEN (crash-consistent, app live), and reported `Backup job finished successfully`, rc 0.** Both images mapped from PBS and mounted read-only (`ro,noload`) on nh3-pve-2, never booted: `svos.db` integrity ok (each image still carries its ~0.9 MB WAL: keep `-wal` with the db when restoring), interface `pins.sqlite3` integrity ok, config/key/config-generation hashes equal live, table counts equal live except `events`. **Monitoring:** `scripts/check-backup-freshness.sh` now reads the LOG of every OK vzdump task and reports ERROR lines; a freeze/thaw error is an APPLICATION-CONSISTENCY FAILURE, verdict **DEGRADED, exit 4** (alerted by the daily wrapper to infra-hermes). nh3-pve-2 was not in the check's node lists at all before 2026-10-05; it is now. Drill B is acknowledged by UPID in the script |
 | Monitoring | Beszel native agent 0.18.7 (`playbooks/beszel-native.yaml`, `configs/beszel-agent/hosts/nh3-svos.env`), hub system `t6y646ifa3x7xxv`, alerts CPU>95%/15m, Disk>85%/5m, Memory>90%/10m, offline/2m. Up 2026-10-05 |

+## Release 6d4cb1c / v0.0.18, U20 settings (2026-10-18 2351–2352; Prime's go 2350 via svos-dev, thread `01M59D7NTZNN75SRP0M4ZQF91A`, and "push it" in-session)
+
+- **Push:** the go came while gitea still had only 15c2d04 (Prime's push never landed). On his "push it", infra-ops pushed
+  svoperatingsystem main `15c2d04..6d4cb1c` (fast-forward) and tag `v0.0.18` → `6d4cb1c64de0` at 2351 from the nh3-dev clone.
+- **Kit:** kernel 0.0.18 (a version bump, no code change), app-interface 0.0.7 wheels and web build UI 0.0.22 from a clean archive of
+  the tag (built from the local tag before the push, same commit). Everything else was carried byte-identical from 15c2d04. Kit sha256
+  `1aec2aa3…`. Playbooks: `nh3-svos-6d4cb1c-v0.0.18-stage.yaml` (2324), then `…-v0.0.18.yaml`. No config change (gen stays
+  `29bc36bf074b8245`).
+- **Cutover:** online sqlite backup `backup/pre-6d4cb1c` (svos.db, briefs.sqlite3, pins.sqlite3, all integrity ok), `current → 6d4cb1c`,
+  front door on UI 0.0.22 (15c2d04 is the previous handle), and **only svos-interface restarted**.
+- ⚠ **The kernel process was NOT restarted.** It still runs 15c2d04's code and reports kernel 0.0.17 until its next restart. That is
+  correct: 0.0.17 and 0.0.18 differ only in the version, and nothing in U20 reads it (svos-dev asked for this note). Knowledge, judge and
+  voice likewise run identical code from the 15c2d04 dir; keep that dir until they restart.
+- **Card:** `card:892d7886…` (manifest, app-interface revision 5, `6759c436e0be`) was raised 2351:50, spoken in ~6 s, and approved by Prime
+  through Matrix at 2352:16. The interface was down (`refused stale`) from 2351:53 to 2352:23. All 8 apps were up again, and the new
+  `state/apps/interface/settings.sqlite3` existed.
+- **After:** Prime's two runtime grants on `ns:interface-settings` (read, not autonomous; write, autonomous) from the page console, then
+  the /settings and panel checks plus his listening test (svos-dev's list).
+- **Rollback:** `current → releases/15c2d04`, run `svos-front-inventory`, restart svos-interface. That reverts the manifest to 0.0.6, which
+  raises another held card. `settings.sqlite3` is additive and can stay.
+
 ## Release 15c2d04 / v0.0.17, seat activity (2026-10-18 2254–2255; Prime's "deploy now" 2235 via svos-dev, thread `01M595YP8R62Y665C38MHPH6YX`)

 - **Kit:** kernel 0.0.17, app-terminal 0.0.6 wheels and web build UI 0.0.21 from a clean archive of the tag. Everything else was