0 Fork 0

mirror of https://github.com/kevinveenbirkenbach/computer-playbook.git synced 2026-11-06 10:59:59 +00:00

Files

T

kevinveenbirkenbachandClaude Opus 5 a35f0a02a2 docs(svc-storage-nfs-server): correct the stale flavor description

Both iteration guides and the nfs_flavor lookup docstring still described
the flavor as RUNTIME conditional, selecting ganesha only for dev and act
and kernel everywhere else. Since the per-variant switching was dropped,
meta/services.yml pins ganesha for every runtime and kernel is a
per-inventory override.

State that, name meta/services.yml as the single point of truth, and
record which os families ship ganesha.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-07-27 23:25:49 +02:00

3.1 KiB

Raw Permalink Blame History

Swarm Loop

Iterate on a swarm deploy of a role through Act and the swarm-* targets. For the compose deploy of the same role, see Compose Loop. For the cross-mode parity gate, see Roundtrip Loop. When Act aborts at "Set up job" on a recent Docker engine, see Workflow Loop.

When to use

Use this loop while actively iterating on or debugging the swarm deploy of a single role through swarm-zombie and the swarm-* targets.
For the compose deploy of the same role use the Compose Loop; for the compose-then-swarm parity gate use the Roundtrip Loop.

The loop

swarm-zombie app=<app> builds a full DinD cluster and leaves it up (INFINITO_KEEP_SWARM_NODES=true) for inspection.
Inspect the live cluster with make swarm-exec / make swarm-shell, then release it with make swarm-down.
Apply the real fix in the repository, then rebuild with a new swarm-zombie run.

Inspect before redeploy

An swarm-zombie run rebuilds a full DinD cluster over tens of minutes, so you MUST confirm a fix on the live cluster before redeploying.

Before every redeploy you MUST fully resolve the failure in swarm and reach at least 95% confidence that your fix actually fixes it. That confidence MUST come from inspecting the live cluster in-container: reproduce the failure, walk the fix path, and confirm the corrected behaviour on the running services. Never redeploy on a guess — a swarm redeploy costs tens of minutes.
The run leaves the cluster up (INFINITO_KEEP_SWARM_NODES=true). You MUST reproduce the failure on it via make swarm-exec / make swarm-shell, then release it with make swarm-down.
You MAY confirm an early-stage fix (config render, realm import) while the run is still going.
In-cluster edits are validation only. You MUST apply the real fix in the repository before the next redeploy.
You MUST NOT commit during an active iteration, because a live deploy makes the pre-commit hook stash the files it reads. If a commit is unavoidable, you MUST pass --no-verify.
For failures the cluster cannot show (app discovery, render-time lookups, multi-node placement), you MUST say so instead of faking an in-cluster check.
When it helps isolate a swarm-only failure from a shared one, you MAY bring up the compose deploy of the same role in parallel (see Compose Loop) purely for comparison and inspection.

Recovery & gotchas

NFS server flavor

The nfs-server uses the userspace nfs-ganesha (ganesha) flavor in every runtime; services.nfs-server.flavor in roles/svc-storage-nfs-server/meta/services.yml is the SPOT, and kernel is a per-inventory override. Ganesha is packaged for the Debian and RedHat os families only. Kernel nfsd in a privileged DinD node is wedge-prone: the export can be present yet the controller mount returns ENOENT, and exportfs can stick in D-state. If a swarm step hangs at Reload NFS exports from a stuck kernel-NFS mount, you MUST recover with make swarm-clean on the host; see the NFS gotcha in Roundtrip Loop. You MUST NOT fall back to a compose-only sweep while swarm is blocked.

3.1 KiB Raw Permalink Blame History