56 lines
3.1 KiB
Markdown
56 lines
3.1 KiB
Markdown
---
|
|
status: active
|
|
initiated: 2026-10-02
|
|
touches: [lab, the lab module, the catalogue, assignments, settings, the controller's store]
|
|
became: []
|
|
---
|
|
|
|
# 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.
|