Files
mesh-catalog/modules/mesh-provisioner
jschoubben 21c86c819c Follow the runtime's watches through mesh-sdk's KeptState.Follow, not four loops of their own (issue 774)
mesh-provisioner, mesh-config, mesh-issues and mesh-healers each wrote a watch-again loop (`watched`). mesh-sdk
61b67d61 adds KeptState.Follow, which asks again with backoff and says each give-up, and its watches now answer a
change at once and run the handler beside the runtime (the provisioner's "names no watch of this bundle"). The four
modules use it; their loops are gone. Built and tested against the mesh-sdk group head through a go.work that is not
committed: their mesh-sdk pins move to that head with the group.
2026-10-30 18:33:32 +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).