The bed bootstraps through the installer, not around it
ADR 0067's own acceptance check said the lab must raise its anchor by running the program a bare machine runs. It did not: whole-mesh-full applied the substrate bundle by hand and then looped enrolment over all four machines as one continuous operation. That gets the order right by accident and models the wrong shape — and an install procedure that exists only as a test fixture is exercised by whoever writes tests and never by whoever installs, which is why every bootstrap fault this year was found late. Two acts now, and the first gates the second. GENESIS is novox running mesh-bootstrap: the installer is built from source before the raise (make bootstrap, carrying the control-plane image built in the same run), placed beside the host binary, given the two manifests it reads, and run. The bed then asserts a WORKING MESH OF ONE — the control plane answers, the registry replies on /v2/, the container called mesh-control is running from a registry-pinned digest rather than an image id, the registry agrees it serves it, temp-mesh-control is gone, and the mesh has heard from its node. The image-id check is ADR 0067's "the pivot completed" verbatim: if it is still an id, nothing was published and this mesh can never roll out its own upgrades. JOINING is ace, shanks and g14: host binary, token, enrol, run. novox is NOT enrolled again — the installer already did it, and a second identity is one the mesh does not know. If genesis stops, the bed prints which of the installer's ten steps it stopped at and goes no further. A second machine joining a mesh that is not ready is a different failure, and running it would bury this one underneath it. The anchor is no longer handed mesh-control:development. Its absence is the point: the installer carries that image inside itself, and handing it over as well would make the load say "already held" and leave the carrying untested — the same class of fiction the lab's own registry used to hide. A unit test asserts the scenario keeps it out. The registry is reached at 127.0.0.1:5000, which is a finding rather than a shortcut: a runtime refuses a plain-HTTP registry at any address but a loopback one, so the digest the control-plane module is pinned to is one only the anchor can pull. Enough here, because only the anchor runs a control plane. Written down in the bed. Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF
This commit is contained in:
+33
-1
@@ -2,7 +2,8 @@
|
||||
* Rebuild what the lab runs, from source, before it runs.
|
||||
*
|
||||
* **A stale artifact reporting success against old rules is the fault this project keeps writing
|
||||
* down** (novox/hq 04-ISSUES/005). The lab consumes three artifacts from two repositories, and they
|
||||
* down** (novox/hq 04-ISSUES/005). The lab consumes a handful of artifacts from two repositories,
|
||||
* and they
|
||||
* were rebuilt by hand, one at a time, from memory. A rename in the control plane's catalogue needs
|
||||
* both the control-plane image *and* the builder binary, because both parse manifests; rebuilding
|
||||
* one left a binary eleven hours old refusing a field the mesh had just renamed, and cost a full
|
||||
@@ -73,9 +74,40 @@ export function planned(env: NodeJS.ProcessEnv = process.env): Build[] {
|
||||
});
|
||||
}
|
||||
}
|
||||
|
||||
// **The installer, carrying the control plane's image.**
|
||||
//
|
||||
// Last, and that is an ordering rather than a preference: `make bootstrap` embeds the output of
|
||||
// `docker save <image>`, so the image has to have been built by the step above or the installer
|
||||
// carries whatever was lying around — the eleven-hour-old artifact again, this time inside a
|
||||
// binary where nothing would ever notice.
|
||||
//
|
||||
// It is built here at all because the bed now bootstraps THROUGH it (novox/hq ADR 0067): the
|
||||
// anchor is brought into existence by running the same program a bare machine runs, rather than
|
||||
// by the bed applying a substrate bundle by hand and calling that an install. An installer that
|
||||
// was stale would be a bed proving something about last week's procedure.
|
||||
const installer = env["MESH_LAB_BOOTSTRAP_BINARY"];
|
||||
if (installer && where["mesh-host"]) {
|
||||
builds.push({
|
||||
what: "installer",
|
||||
in: where["mesh-host"],
|
||||
argv: ["make", "bootstrap", `IMAGE=${controlPlaneImage(env)}`, `BOOTSTRAP_OUT=${installer}`],
|
||||
});
|
||||
}
|
||||
return builds;
|
||||
}
|
||||
|
||||
/**
|
||||
* The control-plane image the installer carries.
|
||||
*
|
||||
* `mesh-control:development` is what mesh-control's `make image` tags, and what the scenarios name
|
||||
* — one tag, said in one place. It is overridable because a release installer carries a release
|
||||
* image, and nothing about that is the lab's business.
|
||||
*/
|
||||
export function controlPlaneImage(env: NodeJS.ProcessEnv = process.env): string {
|
||||
return env["MESH_LAB_CONTROL_IMAGE"] ?? "mesh-control:development";
|
||||
}
|
||||
|
||||
/** rebuild runs the plan, and throws on the first failure rather than testing a stale artifact. */
|
||||
export function rebuild(env: NodeJS.ProcessEnv = process.env): string[] {
|
||||
const built: string[] = [];
|
||||
|
||||
Reference in New Issue
Block a user