diff --git a/03-DESIGN/01-to-be/05-the-node-host.md b/03-DESIGN/01-to-be/05-the-node-host.md index df3ed70..c77fd7d 100644 --- a/03-DESIGN/01-to-be/05-the-node-host.md +++ b/03-DESIGN/01-to-be/05-the-node-host.md @@ -163,11 +163,19 @@ what it is. No control plane, no declarations, no network. Verifiable immediatel the first node's path, and it is the claim the skeleton's Move 1 rests on and has never proved: that one host can raise the substrate alone. -The first vocabulary is bounded by something the lab makes unavoidable: **a scenario is a -closed address space**, so a resource that must be fetched cannot be applied there at all. So -stage 2 begins with what needs no network — files, directories, service state — and the types -that need artifacts wait on where those come from, which is open in -[`02-scenario-declaration.md`](02-scenario-declaration.md). +Raising the substrate needs six shapes in the host's vocabulary, and stage 2 built three: + +| | | +|---|---| +| `directory`, `file`, `service` | **built** | +| `package` | a container runtime must exist before a container can run | +| `container` | pulled by digest ([ADR 0046](../../02-DECISIONS/0046-the-installer-fetches-what-it-pins.md)) | +| `action` | provisioning steps the bundle declares and the host verifies ([ADR 0047](../../02-DECISIONS/0047-the-bundle-may-carry-actions-the-link-may-not.md)) | + +The lab cannot yet exercise the last three: a scenario is a closed address space, so nothing can +be fetched there, and its machines carry no container runtime. That is lab-installation work +([`04-lab-installation.md`](04-lab-installation.md)) rather than a constraint on the design — +production machines have a network. **3 — link and store.** The node connects, receives declarations, and holds what it applied. diff --git a/03-DESIGN/01-to-be/07-the-substrate.md b/03-DESIGN/01-to-be/07-the-substrate.md index de17dd5..1397df9 100644 --- a/03-DESIGN/01-to-be/07-the-substrate.md +++ b/03-DESIGN/01-to-be/07-the-substrate.md @@ -85,13 +85,29 @@ is what keeps the bundle small enough for a person to read and check. The order, from [research 011](../../01-RESEARCH/011-the-module-graph/worked-provider.md): ``` -1 the host applies the bundle the store runs; no mesh exists -2 a database is created in it a provisioning step, done locally -3 the control plane's schema applied a migration against that database +0 a container runtime exists detected, or installed as a package +1 the store runs pulled by digest, from the bundle +2 a database is created in it an action, run locally +3 the control plane's schema applied an action, against that database 4 the control plane starts and only now is there a mesh 5 everything else is provisioned the ordinary path ``` +**Step 0 is easy to leave out and it is where several things meet.** A substrate service is a +container, so something must run containers before anything else happens — and a container +runtime is a *package*, not a container. It is: + +- what the host's capability detection already reports, and the first use of that report by + something other than a person; +- **adopted rather than installed** when the machine already has one with configuration somebody + chose ([research 012](../../01-RESEARCH/012-the-minimum-viable-node/00-overview.md)); +- a package, which needs the machine's own package manager and a network — both permitted by + [ADR 0046](../../02-DECISIONS/0046-the-installer-fetches-what-it-pins.md). + +So the host's bootstrap vocabulary is five shapes: **package**, **container**, **file**, +**directory**, **service**, and **action**. Files, directories and services exist; the rest do +not yet. + **Steps 2 and 3 happen before there is a mesh to do them**, which is why provisioning is part of the bootstrap rather than a service consumers use later. They are **actions** the bundle declares and the host runs