Issues 190, 259, 262: resolved and verified

This commit is contained in:
jochen
2026-10-05 22:56:26 +02:00
parent 178994ee0d
commit 00a0d75ced
3 changed files with 27 additions and 6 deletions
@@ -1,8 +1,8 @@
---
status: located
status: resolved
opened: 2026-10-01
located-in: [mesh-catalog modules/dnsmasq, mesh-catalog modules/docker, mesh-controller internal/overlay/generator.go, mesh-controller internal/catalogue/resolve.go (checkResources), mesh-controller internal/catalogue/seat_into.go, mesh-host internal/apply/apply.go (orphan removal)]
fixed-by:
fixed-by: novox/mesh-controller#62 (d84c969), novox/mesh-catalog#72 (5c89eaf), novox/mesh-host#26 (a192bcc), novox/mesh-controller#63 (c34b937)
amended-design:
---
@@ -109,3 +109,10 @@ gives that module declared settings with defaults. The fix, once both are accept
- **The adopted machine's predecessor values.** The runtime module adopting a file with a
hand-written `dns` and `live-restore: false` replaces both. That is intended, and is the one
restart the operator must make on that machine.
## Verified
2026-10-05: on every machine `insecure-registries` is now the runtime's module's own, filled from the
store's seat; the private network's two generated resources are gone. The handover kept the list
member throughout, and the old reload record was forgotten, not given back ("docker.runtime still
holds the unit"), so the runtime was never stopped.
@@ -1,8 +1,8 @@
---
status: located
status: resolved
opened: 2026-10-05
located-in: [mesh-controller]
fixed-by:
fixed-by: novox/mesh-controller#64 (002d5e5)
amended-design: 03-DESIGN/01-to-be/30-the-mesh-updates-itself-on-a-push.md
---
@@ -39,3 +39,8 @@ says one machine, and the command's output is the only place that says otherwise
- Should the flush send a machine only what changed as a consequence: grants, user lists and bound
facts, not module versions held by a policy?
- Or should it list such machines as behind and leave them, as `push --behind` would find them?
## Verified
2026-10-05: after the fix, a named push sent only the machine named. Upgrades held by a policy were
then sent with `push --behind`, as ADR 0221 has it.
@@ -1,8 +1,8 @@
---
status: located
status: resolved
opened: 2026-10-05
located-in: [mesh-catalog]
fixed-by: novox/mesh-catalog#71 (20603b6)
fixed-by: novox/mesh-catalog#71 (20603b6), novox/mesh-controller#65 (df9231c), novox/mesh-catalog#73 (b4b86c1)
amended-design:
---
@@ -48,3 +48,12 @@ requires one host record per machine should be added.
*2026-10-05:* that test is added with [ADR 0223](../../02-DECISIONS/0223-the-mesh-has-two-resolvers-and-a-machine-lists-only-them.md)
— mesh-controller's composition test renders the resolver's machine list and requires exactly one
host record per machine. The live check stays by hand, on each resolver.
## Verified, and what else was found
2026-10-05: the host record fixed the IPv6 answer, but Alpine programs still failed when they read the
machine's resolver file directly (host networking, docker's default bridge). They asked the mesh's
resolver and the public fallback at once and took the public "no such name". ADR 0223 removes the
public fallback: a machine lists only the mesh's resolvers, now two. Afterwards an Alpine container
resolved a machine's name ten times out of ten, with host networking and on the default bridge, and
the build machines built with no hosts-file line.