4.9 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| resolved | 2026-09-28 |
|
mesh-controller PR 192 (a report carries the profile), mesh-host PR 61 (uplink-<manager> detected and reported with every apply), mesh-catalog PR 206 (each holder declares its own) |
|
138 — Two modules claim one seat and are not interchangeable, and nothing says so
What was observed
Three modules claim the node-scoped uplink seat: one for each network manager a machine here might run. ADR 0117 gives each of them the same job — ask the manager the machine already runs to leave the resolver file alone and to leave the mesh's interface alone — and deliberately keeps the machine's own links out of the mesh's hands.
A seat means one holder and an interchangeable holder. These are interchangeable in what they ask and not in what they do:
- None installs, enables, starts or stops the manager. That is on purpose: stopping it takes every link down, including the mesh's own way in.
- None carries an address, a route or a wireless credential, for the same reason.
- Nothing checks that the module holding the seat names the manager the machine is actually running. Assigning the systemd-networkd holder to a machine running NetworkManager writes a file for a daemon that is inactive and disabled, the seat reports held, and the two things the seat exists to arrange are arranged for nobody. NetworkManager goes back to rewriting the resolver file on every lease, which is the failure the module's own comment describes.
The machine reports which service manager and which units are active, so the fact needed to catch this is already in the report the mesh holds.
Why it matters beyond this instance
A seat is the mesh's promise that a role is filled. If the holder can be a module for software that is not running, the seat says a role is filled while nothing fills it — and the surface that would tell an operator says "held".
It is the same shape as two faults found the same day. A module named a firewall front-end the machine does not have (issue 136), and the filter named address ranges one runtime happens to use (issue 137). Each is a claim about the machine that nothing on the machine checks.
And it decides whether the seat is worth having. Either the holder must match what the machine runs, which is a condition the mesh can check from the report it already has, or the holders must be able to switch the manager, which ADR 0117 refuses for a reason that has not changed.
Open questions
- Should a seat's conditions of holding include a capability the machine reports, so a holder naming absent or inactive software is refused rather than recorded?
- Is "the uplink" one seat at all, if its holders are three dialects of the same two requests? The alternative is one module that speaks whichever dialect the machine needs, chosen from the report.
- What should happen on a machine that switches manager afterwards? The seat would then be held by the wrong module, and the machine is the only place that knows.
Decided, 2026-10-01
ADR 0161, rule 3: the host's profile gains one capability per network manager found active, each holder declares its own, and the existing capability refusal does the rest, naming it. The profile is detected again by every apply and travels in the report, so a machine that switches managers is refused at its next push. The uplink stays one seat; the capability picks the dialect. Order of building: controller (a report may carry a profile), host, then the three definitions.
Resolved, 2026-10-01
Every machine now reports which network manager it runs — the control node uplink-systemd-networkd,
the laptop and the workstation uplink-networkmanager, the home server both uplink-dhcpcd and
uplink-networkmanager, which is its truth — renewed with every report, and each holder declares the
capability it needs, so the wrong holder is refused on assignment with the capability named. The uplink
stays one seat; the capability picks the dialect. A machine that switches managers is a machine whose
holder lacks a capability at its next push.
How it is checked: the host's detector test per manager; the controller's test that a report's
profile replaces the enrolled one; the capability refusal's existing tests; live, node show <machine>
lists uplink-<manager> for each.