From d222091fe9d49bb2215e4c7a818c76f3ff8739b3 Mon Sep 17 00:00:00 2001 From: jochen Date: Mon, 5 Oct 2026 14:54:38 +0200 Subject: [PATCH] Issues 245, 246; 240 resolved, 242 located MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 245: a media server's previews were reached through a link its container never mounted — fixed by mounting them. 246: settings set replaces the whole layer with nothing to read it first and no history. 240 is fixed by mesh-controller#47; 242 has backups running and records what the rollout taught. --- .../00-report.md | 14 ++++-- .../242-the-mesh-has-no-backups/00-report.md | 30 +++++++++++-- .../00-report.md | 39 ++++++++++++++++ .../00-report.md | 45 +++++++++++++++++++ 4 files changed, 122 insertions(+), 6 deletions(-) create mode 100644 04-ISSUES/245-a-media-servers-previews-were-reached-through-a-link-its-container-never-mounted/00-report.md create mode 100644 04-ISSUES/246-setting-a-modules-settings-replaces-the-whole-layer-and-nothing-shows-it-first/00-report.md diff --git a/04-ISSUES/240-a-dry-run-build-is-recorded-and-rolled-out/00-report.md b/04-ISSUES/240-a-dry-run-build-is-recorded-and-rolled-out/00-report.md index 51cc62d..ef3ccd8 100644 --- a/04-ISSUES/240-a-dry-run-build-is-recorded-and-rolled-out/00-report.md +++ b/04-ISSUES/240-a-dry-run-build-is-recorded-and-rolled-out/00-report.md @@ -1,8 +1,8 @@ --- -status: open +status: resolved opened: 2026-10-04 -located-in: [] -fixed-by: +located-in: [mesh-controller cmd/mesh-controller/main.go, mesh-controller cmd/mesh-builder, mesh-controller internal/link/build.go] +fixed-by: mesh-controller#47 amended-design: --- @@ -35,3 +35,11 @@ acts on it, review becomes a formality: the unreviewed definition reaches a mach 1. Where does the dry run's outcome enter the record — the build machine's `built` event, consumed as any other build's? 2. Did the controller roll the dry run out, or did a later push compose from it? + +## Resolution (2026-10-05) + +A dry run is marked on the request (`DryRun`), the builder echoes the mark on its outcome, and the +controller's daemon sets a marked outcome aside: no record, no registration, no plan, nothing a push +could send (mesh-controller#47, with a test that the daemon takes a dry run in with no store at all). +Left open as a follow-up: the catalogue module also hears build outcomes and records their edges; it +should skip a dry run too. diff --git a/04-ISSUES/242-the-mesh-has-no-backups/00-report.md b/04-ISSUES/242-the-mesh-has-no-backups/00-report.md index 0821cef..3157f96 100644 --- a/04-ISSUES/242-the-mesh-has-no-backups/00-report.md +++ b/04-ISSUES/242-the-mesh-has-no-backups/00-report.md @@ -1,8 +1,8 @@ --- -status: open +status: located opened: 2026-10-05 -located-in: [] -fixed-by: +located-in: [mesh-controller internal/catalogue/seats.go, mesh-catalog modules/restic] +fixed-by: mesh-controller#49, mesh-catalog#49, mesh-catalog#54, mesh-catalog#55, mesh-catalog#56, mesh-media-catalog#1 amended-design: 03-DESIGN/01-to-be/43-backups-against-mistakes.md --- @@ -47,3 +47,27 @@ research 030; proposed as ADR 0214. Issue 241's recovery cost a night and lost the forge's records of twelve days. With a nightly backup held on another machine, it would have been a ten-minute restore of yesterday. + +## Where it stands (2026-10-05) + +Backups run (ADR 0214, to-be 43): the control node keeps nightly restore points of its eight stores +and services, the home server of its databases and its media apps' libraries and cover art; each on +its own machine, on its larger filesystem. The first runs were tried one module, then two, then a +whole node, each proven by a restore beside the live data. Not yet built, which is why this stays +open: the weekly test restore into a throwaway instance, the 48-hour status line, and failures +reaching the operator rather than the holder's log. + +What the rollout taught, for the next module that takes contributions: + +- **A contribution makes the contributing module depend on the seat.** Merging the stores' + contributions before a holder was assigned left every node's plan unresolvable — the whole mesh, + not only the machines running a store — until the holder was assigned. Assign the holder in the + same step as the merge. +- **A brand-new module is not built by the push that adds it**; its first build is asked for by hand. +- **The holder must look as the account that can see.** Its first run called a store's dumps missing + because it checked as the runtime's account, which cannot see inside the store's own directory. +- **A kept single file is not a directory.** restic restores a snapshot's subfolder, not a file; + the first restore of a module keeping its settings file refused it. +- **An update kills a running backup** — the holder's restic is its child. A hand-off to the new + version, the run living on as its own unit under the machine's service manager, is the idea to + take forward. diff --git a/04-ISSUES/245-a-media-servers-previews-were-reached-through-a-link-its-container-never-mounted/00-report.md b/04-ISSUES/245-a-media-servers-previews-were-reached-through-a-link-its-container-never-mounted/00-report.md new file mode 100644 index 0000000..cf9dff0 --- /dev/null +++ b/04-ISSUES/245-a-media-servers-previews-were-reached-through-a-link-its-container-never-mounted/00-report.md @@ -0,0 +1,39 @@ +--- +status: resolved +opened: 2026-10-05 +located-in: [mesh-media-catalog modules/plex] +fixed-by: mesh-media-catalog#2 +amended-design: +--- + +# 245 — A media server's previews were reached through a link its container never mounted + +## What was observed + +On the home server the media server's scrub previews — 423 GB, about 57 000 preview files, one per +video — had not grown in seven months: the newest was from the day its preview folder was moved off +the server's own disk onto the large storage pool. The server's log repeated, live, that it could not +create a directory under its preview folder. + +## Why + +The move left the preview folder as a **symbolic link** inside the server's configuration directory, +pointing at the pool. The container mounts the configuration directory and the media libraries, and +not the pool's path, so inside the container the link pointed at nothing: the server could neither +show the previews it had nor make new ones, and said so only in its own log. Nothing the mesh reports +showed it — the container ran, and answered. + +It is the failure the mesh's rule against symbolic links exists for: a link resolves differently in +every place that reads it, and a container is such a place. + +## Resolution + +The previews are a directory of the module, mounted at the server's preview path; where that +directory lives on a machine is the machine's placement setting, here the pool path the files were +already in. The link was removed at the cutover, the container recreated, the preview folders visible +inside it again and the log's errors gone. The previews are not backed up, by the operator's choice. + +## How it is checked + +The catalogue check that every mount is declared passes over the module. On the machine: the preview +folder seen from inside the container lists the same folders as the pool path. diff --git a/04-ISSUES/246-setting-a-modules-settings-replaces-the-whole-layer-and-nothing-shows-it-first/00-report.md b/04-ISSUES/246-setting-a-modules-settings-replaces-the-whole-layer-and-nothing-shows-it-first/00-report.md new file mode 100644 index 0000000..a0aa0a2 --- /dev/null +++ b/04-ISSUES/246-setting-a-modules-settings-replaces-the-whole-layer-and-nothing-shows-it-first/00-report.md @@ -0,0 +1,45 @@ +--- +status: open +opened: 2026-10-05 +located-in: [mesh-controller cmd/mesh-controller (settings), mesh-controller internal/inventory (SetSettings)] +fixed-by: +amended-design: +--- + +# 246 — Setting a module's settings replaces the whole layer, and nothing shows it first + +## What was observed + +An operator's agent set one placement — where a media server's preview folder lives on one machine — +with `settings set {"places": {…}} --node `. The command answered that the setting +was recorded. The machine's plan then mounted the server's configuration from an empty default +directory: the node's layer had held the placements of three other directories, eight media +accesses, a public exposure, four endpoints and the account's ids, and every one of them was gone. + +Caught before any push, by reading the plan. The previous layer was read back from the controller +database's nightly dump — the backups that issue 242 asked for, a few hours old. + +## Why + +The layer is a statement of the whole, by design (the inventory's `SetSettings`: "replacing rather +than merging … removing a key is done by leaving it out"). That design is sound; what is missing +around it is everything that makes it safe to use: + +- **There is no way to read a layer.** `settings` has `set` and `clear`, no `show`; the console verb + likewise. To change one key, a person must already know every other key in the layer. +- **There is no history.** The row is updated in place; the previous values exist nowhere but a + database backup. +- **The answer does not say what was dropped.** "places" was reported as set; the six keys removed + were not mentioned. + +## What would fix it + +1. A way to read a layer — `settings show [--node]` and the same on the verb. +2. `set` answers with what changed: keys added, changed and **removed**, so dropping one is never + silent. A removal could even require saying so. +3. The previous value kept: a settings history row per change, so an undo needs no backup. + +## Status + +Open. Until it is fixed: read the layer (from the store, read-only) before setting it, and compare +the node's plan before and after.