mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-09 20:26:33 +00:00
kevinveenbirkenbachandClaude Fable 5
14b41c8025
Docker mounts a volume that declares its own backing store (Options set: nfs, cifs, bind) only while a container holds it. recover.py resolved the volume's Mountpoint and rsynced into it regardless, so with the consuming stack stopped - the state its own docstring demands - the payload landed on the node's disk under the bare mountpoint directory, and the next stack start mounted the real backing store over it: a restore that reports success, delivers nothing, and leaves an invisible, unreclaimable orphan behind. That orphan had weight. In run 30859490335 the swarm drill's [9/9] volume leg restored ~1 GiB of nextcloud_data onto the manager's 30 GiB loop device in exactly the minute the device crossed SeaweedFS's 2 GiB minFreeSpace floor - the last straw on a device already >=93% consumed (the sizing is ea14535f4) - after which every authenticated Nextcloud request died on an unwritable object store. recover.py now probes the mountpoint with `mountpoint -q` (over ssh for --docker-host) whenever the volume declares Options, and dies naming the mechanism and the way out instead of writing a single byte. Plain local volumes without Options keep the old path untouched - their _data directory on the node disk is the legitimate target. The drill skips its [9/9] volume leg for such volumes with the reason in the log: its data restore already happens in [8/9] straight into the NFS export, which is the restore path the role's README prescribes for NFS-backed volumes on swarm. The leg never proved anything for them - it only filled the disk. Three new unit tests pin the contract: unmounted refused, mounted accepted, remote probed via ssh with the exact command line. 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.