jschoubben
b4904fec7e
The lab was designed around a module under test, with a scenario being a complete mesh — forge, coordinator, cascade, verify. That is unusable for building the new mesh, because all four are tier 2 and do not exist yet. And research 009 had the sequence backwards. It placed the lab at phase B as verification of tiers already built, but tier 0 is the component that takes over a machine's packages, services and network. It cannot be developed against a machine anyone needs. The lab has to exist before the thing it will test. ADR 0029 splits scenarios into two classes. The bootstrap scenario is virtual machines, the host binary and a pinned bundle, with the verdict coming from what the host reports about the state it reconciled. The full scenario is the designed one. The first is a strict subset of the second — same virtualisation, same networking, same lifecycle, stopping before a control plane exists — so the second is reached by addition rather than rework. The consequence worth having: raising a node from nothing stops being the least-exercised path in the system and becomes the inner development loop. It also settles the runner's two jobs. Scenario lifecycle is needed immediately, because something must materialise and reset a mesh before anything can be written against it. Assertion execution waits for the full scenario. Corrects a stale claim in the design while amending it: it argued scenarios were affordable with system containers and would not be with virtual machines. ADR 0016 superseded that reasoning and the text had not followed. Issue 007: the lab's first requirement is installed and unusable. The virtualisation package is present and explicitly installed; both units are disabled, the operator is in no group, and the client reports the server unreachable. Not issue 001 again — that is an install failing while reporting success. This is an install succeeding when success was not the point. A package is files; a capability is a running service and an identity permitted to reach it, and the module model has no vocabulary for the second.
3.0 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | |
|---|---|---|---|---|---|
| open | 2026-08-23 |
|
007 — An installed package is not an available capability
Symptom
A module declares the virtualisation package the lab needs. The package is installed — version 7.3.0-1, recorded as explicitly installed. The client binary runs.
The capability does not exist:
| Checked | State |
|---|---|
incus.service |
disabled, inactive |
incus.socket |
disabled, inactive |
incus-user.socket |
disabled, inactive |
| the operator's group membership | not a member of any incus group |
| the client | reports Server version: unreachable |
Nothing failed. Nothing reported anything. The declaration was satisfied exactly as written, and the thing it was declared for cannot be used.
Why this is not issue 001 again
Issue 001 is the install failed and the job reported success. This is the opposite and arguably worse: the install succeeded, and success was not the point.
A package is a set of files. A capability is a running service, an enabled socket, and an identity permitted to reach it. The module model declares the first and has no vocabulary for the second, so the gap between them is invisible — there is no state in which the mesh believes this node has virtualisation and is wrong, because the mesh was never asked to believe it.
The distance between the two is the same one the delivery layer already has a name for: transport versus effect. A package install reports that files arrived, which is transport.
Why it matters now
This is the first requirement of the lab (ADR 0029), which is phase 0 of the entire migration. The first capability the new work depends on is present, declared, and unusable — and would have stayed unusable silently.
It also generalises. Every module that declares a package needing a unit enabled, a group joined, a kernel module loaded, or a socket activated has this gap. Post-install work lives in hooks, and hooks have their own recorded failure mode: thirteen were found that had never run.
Evidence
- Package recorded as installed 2026-08-23 00:02, explicitly.
- Both units disabled and inactive; the operator in no incus group; client reports the server unreachable.
Open questions
- Should a module be able to declare a capability — a unit that must be enabled, a group the operator must be in — rather than only the package that provides it?
- If that is what hooks are for, why is the gap invisible when a hook does not run? A hook that never fires and a hook that fires and does nothing are indistinguishable today.
- Is this what the verify stage should be asserting? It exists, and a module's own assertions are meant to test outcomes rather than steps — "the socket accepts a connection" is exactly that shape.
- How many other declared packages are in this state? Nothing currently reports it, which means the answer is unknown rather than zero.