Issues 190, 259, 262: resolved and verified
This commit is contained in:
+9
-2
@@ -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.
|
||||
|
||||
+11
-2
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user