mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-09 20:26:33 +00:00
kevinveenbirkenbachandClaude Fable 5
a3839e57f0
Every lab node got an identical 30 GiB loop device because docker_dataroot.sh defaulted SIZE to 30G and no caller ever stated it. The swarm manager hosts the in-cluster registry, ~60 containers, and - by deliberate placement, since /data is NFS-unsafe - the SeaweedFS object store, whose sizing filter claims 14 GiB of slots plus a 2 GiB minFreeSpace floor. The idle nfs-server node got the same 30 GiB and used 1% of it. In run 30859490335 the manager's device stood at 30G/30G (98%), SeaweedFS crossed its floor at 02:04:45 and marked all 14 volumes unwritable, permanently. Nextcloud in variant 0 stores objects in that SeaweedFS via OBJECTSTORE_S3_*, so every authenticated page render performed an object write that failed as a 10-attempt assign ladder - 15 requests, 15 bursts of exactly 10, burst end matching the nginx 500 to the second. That is the "🐝 web-app-nextcloud 0" failure: 5 addon specs, 3 attempts each, all dead on the post-login page. The default is gone: SIZE is now a required argument and a missing value dies naming the call site. The swarm playbook states it per node - 60G for the manager, 30G for the rest. 60G covers the observed demand (>=31 GiB: a full device plus the denied writes) with headroom; the image is sparse, so the raised ceiling costs only what is actually written, and the runner-side watchdog at 6 GiB free remains the backstop. The compose and host workflows state their unchanged 30G explicitly. Not addressed here: what fills the first 28 GiB (registry + image layers + volumes composition is unmeasured - the rescue artifact holds exactly one df snapshot), and the drill-side shadow restore that supplied the last ~1 GiB; both are separate changes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Script Collection
This directory contains automation scripts used across the project.
-
system/ contains host and system-facing helpers.
-
container/ contains helpers that run inside the local container.
-
github/ contains GitHub workflow helper scripts.
-
For the canonical Make target index, see make.md.
-
🛠️ Organize operational helpers for development, CI, release, and maintenance
-
🧭 Separate responsibilities into focused subdirectories with clear scope
-
📚 Keep script-based workflows discoverable and easier to navigate
The scope of this folder is script organization at the repository level. Detailed responsibilities belong in the README files of the respective subdirectories.