jschoubben
e1febe8e0f
The consolidation left a sparse sequence -- 1, 4, 6, 7, 9, 10, 12, 15, 16, 18, 19, 25, 34, 35, 36, 37, 40, 42, 44, 45, 48, 49, 58 -- where the gaps were only the archaeology of what used to be there. Renumbered contiguously. Renames run in ascending order, so every target number is already free and no two files ever collide. The reference rewrite is one simultaneous pass rather than a sequence of replacements. Numbers moved into slots other numbers were vacating -- the node host went 37 to 16 while the lab went 16 to 9 -- so replacing one at a time would have cascaded and silently pointed things at the wrong record. Seven plain-text references survived the merges as prose rather than links, naming records that no longer existed: the enrolment token, the link boundary, what a declaration is, reachability, the repository structure. Each mapped to the consolidated record that now holds it. Verified rather than assumed: every [ADR NNNN](path) link now has matching text and target, checked across the whole repository, and the checker passes. Frontmatter `consolidates:` lists dropped -- they named records that are gone, and each consolidated record already says in prose what it absorbed.
52 lines
3.1 KiB
Markdown
52 lines
3.1 KiB
Markdown
---
|
|
status: active
|
|
initiated: 2026-08-23
|
|
touches:
|
|
- 03-DESIGN/00-as-is/03-provisioning.md
|
|
- 02-DECISIONS/0019-modules-and-the-graph.md
|
|
- 01-RESEARCH/006-mesh-from-scratch/code-skeleton.md
|
|
became: []
|
|
---
|
|
|
|
# 007 — Provisioning as the mesh's core mechanism
|
|
|
|
## What is being investigated
|
|
|
|
Provisioning is the mechanism the whole mesh rests on: a module declares what it needs, and the
|
|
mesh makes it exist, generates the credential, records the grant, and puts the values where the
|
|
module will read them. [ADR 0019](../../02-DECISIONS/0019-modules-and-the-graph.md)
|
|
calls it the mesh's core concern rather than its plumbing.
|
|
|
|
[Research 006](../006-mesh-from-scratch/code-skeleton.md) then asks it to carry **more**: the
|
|
control plane becomes a consumer with its own requirements — a source of record, an image
|
|
registry, a package registry — satisfied by the same mechanism. That generalisation is only
|
|
safe if the mechanism is sound, and the as-is record says it is not, in named ways.
|
|
|
|
## Why now
|
|
|
|
Four weaknesses are already documented in
|
|
[`03-DESIGN/00-as-is/03-provisioning.md`](../../03-DESIGN/00-as-is/03-provisioning.md), each
|
|
observed rather than theorised:
|
|
|
|
- **Rotation has no fan-out.** A shared credential can be rotated without telling the peers
|
|
holding the old one. This has locked the mesh out of its own broker.
|
|
- **A grant is not a check.** The record says a resource was provisioned. Nothing verifies it
|
|
still exists, still has that credential, or is reachable from where the consumer runs.
|
|
- **A frozen password outlives its generation.** A generated secret written once diverges from a
|
|
persistent data directory initialised earlier, and presents as an authentication error.
|
|
- **No requirements is indistinguishable from provisioning that did not run.** A module that
|
|
declares nothing skips the stage, which is correct, and looks identical to failure.
|
|
|
|
Generalising a mechanism with these properties to the control plane's own dependencies would
|
|
make each of them fatal rather than annoying.
|
|
|
|
## The questions
|
|
|
|
| Question | Why it matters |
|
|
|---|---|
|
|
| What does a **grant** mean, exactly — a record that a resource was created, or a claim about the world that is continuously reconciled? | The difference between the current model and one where "provisioned" is checkable. Almost every weakness above is a symptom of the first answer. |
|
|
| How is a credential **rotated** with fan-out to every holder? | The mechanism grants easily and regrants not at all. This is the most damaging gap and it has taken the mesh down. |
|
|
| Can the **control plane** hold requirements, and what satisfies them before anything is installed? | The generalisation research 006 needs. Ties directly to the self-hosting transition. |
|
|
| What happens when a requirement **cannot** be satisfied — no provider, provider on an unreachable node, provider not yet installed? | Today this is silent or a stall. It should be a stated, visible state. |
|
|
| Does a requirement belong to a **module** or to one of its **parts**? | Research 006 splits `feature` into artifact and part. A part-scoped requirement means a database is not provisioned where the part that needs it is not installed. |
|