3.1 KiB
status, initiated, touches, became
| status | initiated | touches | became | ||||||
|---|---|---|---|---|---|---|---|---|---|
| active | 2026-10-02 |
|
019 — A warm twin of the running mesh
What is being investigated
Whether the lab can keep a warm twin of the mesh as it actually runs: the same machines, carrying the same catalogue, the same assignments and the same settings as the live mesh, raised once and kept ready, so that a change can be tested against the mesh as it is rather than against a scenario written to resemble it. A run against the twin would go through the lab module like any other run: a branch per repository, the twin restored from its snapshot, the change applied, the beds run.
Why
The lab's beds raise meshes from declarations written for the bed. They prove the mechanism. They do not prove that a change works on the mesh that runs, with its accumulated assignments, its operator settings, its adopted machines and its modules in their real combinations. The gap showed on 2026-10-02:
- a change to how a module's settings reach its files was correct in every bed, and would have put a setting into the container runtime's configuration on every machine running that module. Only the composed plan for a real machine showed it;
- a firewall change composed cleanly and still left one machine's wired port unfiltered, because of a link that machine had and no bed did;
- a recovery step was needed on every machine at once, after a change that every bed had passed.
The lab already has a warm mode, a snapshot of a raised scenario restored between attempts. What it does not have is a scenario that is the running mesh, kept current with it.
What it touches
- What a twin is made of. The catalogue and the assignments are records; settings are records; secrets are sealed to machines and cannot be copied. Which of these can be carried to the lab as they are, which must be substituted, and how a twin says what it substituted.
- Data. A twin with the real catalogue and no real data proves composition and delivery, not a migration. Whether a twin carries data, a sample of it, or none.
- Keeping it current. A twin raised once goes stale with the first merge. Whether it is re-derived from the live records on each run, refreshed on a schedule, or rebuilt only when asked.
- Machines. The live mesh has machines of different kinds: a server on the internet, machines behind a home router, a laptop that sleeps. Which of their properties a twin must reproduce for a test to mean anything (reachability, the private network, the found firewall).
- Cost. The lab machine's memory and disk, and how long a twin takes to raise from cold.
- The lab module's tools. A run against the twin rather than a named bed: one more tool, or an argument to the run tool.
Starting point
The lab module (ADR 0172) runs beds through the mesh, and the lab's warm mode already snapshots and restores a raised scenario. The beds that raise a machine shaped like one live machine from the catalogue are the nearest existing thing, and the first to compare against.