ADR 0102: the mesh writes into a shared file, never over it; issue 084 located

2026-09-22 17:46:06 +02:00
parent 1901a90d68
commit 84761f0600
3 changed files with 98 additions and 2 deletions
@@ -1,7 +1,7 @@
 ---
-status: open
+status: located
 opened: 2026-09-22
-located-in: []
+located-in: [mesh-control internal/overlay, mesh-host internal/apply]
 fixed-by:
 amended-design:
 ---
@@ -55,3 +55,14 @@ and nothing checks for it today.
 - Which other modules declare a whole file that other software on the machine also writes?
 - Should an adopted node that cannot trust the registry be refused a module that needs to pull?
  Or should the refusal come earlier, when the node joins?
+
+## Diagnosis
+
+*2026-09-22.* Worse than reported. The controller's "merge" of the runtime's file merges an
+operator's settings into the module's content. The host then writes the result **whole**, so a
+machine's own runtime settings, including its data directory, are replaced, not added to.
+Measured on a lab machine: the runtime takes a new trusted-registry list on a reload, and a
+running container without a restart policy survives it. Decided in
+[ADR 0102](../../02-DECISIONS/0102-the-mesh-writes-into-a-shared-file-never-over-it.md): the
+runtime's file is written into and the runtime reloaded. The hosts file stays a whole file, held
+until networking is taken.