Files
mesh-catalog/modules/mesh-provisioner
jschoubben 2d2eb5dffb mesh-provisioner: make every plan from the node-engine's published compositions
The node-engine alone composes (ADR 0593 §6, §8), so the provisioner stops
composing with frombus and fromruntime and reads each module's plan from
composed-<node> (read as mesh-host.composed): at its want, or the build its
have runs, and at the indexer's newest build, so a key ahead of its want
still carries its plan entry. A refused or not yet published composition
holds the module with its last plan kept. The golden test proves the plans
and provisions are today's, captured from the composing holder before the
change. It no longer reads the builds or the resolved values.

Claude-Session: https://claude.ai/code/session_01NcbgfJ9Gum47zkFKWRaovL
2026-11-02 18:20:39 +01:00
..

mesh-provisioner

Holds the mesh-provisioner seat once for the mesh: the provisioner's server (novox/hq ADR 0349 clause 3, design 57 P4). Go, one binary (cmd/mesh-provisioner), served by a runtime of its own on its own bus account (runs-as), so that its account alone writes the registry. The provisioner client on each node (node-provisioner, design 57 P5) is the module mesh-provisioner-client.

What it keeps

  • mesh-provisioner_registry: which domain answers which kind of placeholder, keyed by the kind (config, secret, bound — the provider's own bucket, <provider-module>_bound, keyed <node>.<module>.<provision>[.<local>] (mesh-sdk go/provider) — consumers — a provider's consumers' credentials, asked of the vault by the provider machine's client (novox/hq ADR 0373) — collected — and shell, environment and contribution, read as collections of the same name (design 57 L1) — and the placement namespaces dir, access, port, seat, machine). Each answer names the owning module and where a client finds the values: a domain's bucket and its key shape (placement's is the controller's assignments mirror, whose value carries the provisioner's plan of a module handed to it), or a seat's verb asked on request and reply (a secret is never in a bucket). Compiled in registry.go, written at start and every hour, only where it differs; a kind no domain answers is deleted.
  • mesh-provisioner_needs: what each module on each node needs, <node>.<module>.<kind>.<name>.
  • mesh-provisioner_applied: what is applied where, <node>.<module>.
  • mesh-provisioner_collect: the items of every collection, <node>.<collection>.<contributor>, the collection with a character a key's token cannot hold written =<hex> (shell=3Azsh=3Anormal is shell:zsh:normal), and read back by its name.

The last three are written by each node's provisioner client for its own node's keys alone: the controller grants the client <node>.> of each and nothing wider (mesh-controller internal/broker/provisioner.go), and a provider reads the needs without writing them. This module writes only the registry.

The verb

mesh-provisioner.provisioning with what registry (the default), needs, applied or collect, narrowed by node and module (for collect, the contributor) and, for collect, collection. Reads only. A key out of its bucket's shape is said in the answer, never dropped quietly.

Files it does not know

Each directory or archive this module declares says how it treats a file it did not write (ADR 0422, ADR 0416).

  • ${dir:state}: everything in it is the program's; the mesh moves nothing out (ADR 0422 §2).