jschoubben
5cac268457
Correcting design 26 to match what the merged code does, and fixing issue 112's status, which used a word the vocabulary does not have. A claim on a seat the manifest does not itself declare is refused at registration rather than by the parser. A module may hold a seat another module declared — that is why ADR 0126 has a caller name the seat and not its provider — so whether the name exists is a fact about the whole catalogue. And a declared seat may promise nothing. That is a marker seat, and most node-scoped seats are markers: which module is this machine's packet filter. ADR 0126's "a declared seat carries a protocol" says what a holder must satisfy, not that every seat offers something. `records.py` still fails on ADR 0120 resting on a proposed ADR 0112, which is not this branch's and not mine to decide.
52 lines
2.8 KiB
Markdown
52 lines
2.8 KiB
Markdown
---
|
|
status: resolved
|
|
opened: 2026-09-24
|
|
located-in: [mesh-controller internal/inventory, mesh-controller internal/catalogue, mesh-controller cmd/mesh-controller, mesh-catalog modules/dnsmasq]
|
|
fixed-by: [mesh-controller#73 overlay-name + namesInTheMesh, mesh-catalog#106 dnsmasq daemon.json merge]
|
|
amended-design:
|
|
---
|
|
|
|
# 112 — Adopting a tunnel gives the mesh the peers' addresses but not their names
|
|
|
|
## What was observed
|
|
|
|
On the control-node, 2026-09-24, reading what the resolver would answer before it was assigned.
|
|
|
|
The predecessor's resolver answers for **four** machines — the hub and the three that reach it over
|
|
the tunnel. The mesh's would have answered for **one**: itself. The other three are *carried peers*
|
|
of the tunnel the hub took over
|
|
([ADR 0105](../../02-DECISIONS/0105-the-mesh-adopts-the-predecessors-tunnel-in-place.md)) — the mesh
|
|
holds an address for each, and keeps it, and has no name for any of them, because a name comes from
|
|
enrolling and they have not enrolled.
|
|
|
|
Taking the resolver in that state replaces a file that resolves four machines with one that resolves
|
|
one, and — because the resolver is told the mesh's suffix is its own and forwards nothing under it —
|
|
the other three stop resolving rather than falling through. Everything on the machine that reaches
|
|
another by name breaks at once: the predecessor's own agents, its pipeline, anything an operator
|
|
typed.
|
|
|
|
## Why it matters beyond this instance
|
|
|
|
Adoption was designed so that what the mesh does not know yet, it leaves alone. The tunnel is the
|
|
first place the mesh takes over something whose *content is knowledge the predecessor has* — three
|
|
machines exist, and these are their names — and it takes the addresses without the names. Nothing
|
|
says so; the mesh reads as complete.
|
|
|
|
This is an ordering rule the migration did not have: **a name the predecessor answers for must keep
|
|
resolving until the machine behind it is a node.** It applies to the resolver first and to anything
|
|
else derived from "the machines the mesh knows" while the mesh knows fewer than the machine does.
|
|
|
|
## Open questions
|
|
|
|
- Should a carried peer be nameable — the operator saying which machine a carried address is, before
|
|
it enrols — so the resolver can answer for it in the meantime? The mesh would be recording a name
|
|
it cannot verify.
|
|
- Or should the resolver simply not be taken until every carried peer has enrolled, stated as a
|
|
refusal rather than a note in a runbook?
|
|
- Or should the mesh's resolver, while any peer is carried, forward the suffix it cannot answer to
|
|
the resolver it replaced — which is the adapter shape
|
|
([ADR 0104](../../02-DECISIONS/0104-a-provision-may-be-answered-by-an-adapter-to-the-predecessor.md))
|
|
applied to names instead of routes?
|
|
- What checks it? Nothing compares what the predecessor's resolver answers with what the mesh's
|
|
would.
|