jschoubben
333356cff3
Jochen asked whether the order made sense. It did not -- it followed when things happened to be decided, which after consolidation is fictional anyway since record 5 alone folds decisions taken across a week. Concretely wrong before: the domain statement sat at 8, after five engineering rules; the constitution was scattered across 5, 12 and 17; the tiers landed at 15, 16, 21 and 22 with process records in between. Now it walks: what the mesh is (1-3), its tiers from the bottom up (4-8), what runs on them and how it gets there (9-10), how it is built (11-16), how it is checked (17-18), how we work (19-23). Two things made this safe rather than free. It is a permutation, not a compaction, so the renames go through temporary names -- otherwise two files want one slot and one is lost. And the reference rewrite is a single simultaneous pass, because almost every number moved into a slot another number was vacating; replacing one at a time would have cascaded and pointed things at the wrong record while still resolving. Verified: 284 [ADR NNNN](path) links across the repository, all with matching text and target. The ordering principle is now stated in 19 rather than left implicit -- the repository already said "the numbering is the flow" about its folders, and there was no reason for the records to be the exception.
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/0009-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 0009](../../02-DECISIONS/0009-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. |
|