Files
mesh-controller/examples
jochen ef3e5ae9b0
mesh/merge-gate head ef3e5ae9b0dc merged into trunk 1d244d5aa24e — pass: builds build-agent, mesh-controller, route-proxy → ace, g14, novox, shanks; no bus…
mesh/repo-check head ef3e5ae9b0dc merged into trunk 1d244d5aa24e — pass: its merge-check.sh passed
mesh/delivery delivered
Stamp no commit in this repository's own image recipes either (hq issue 363, review of #292)
The genesis image copies the whole clone with .git, so its controller
carried the commit it was built at, as the bundles did.
2026-10-13 06:47:18 +02:00
..

examples

Things that run, kept here because a contract is easier to read as working code than as prose.

Nothing here is part of the control plane. The control plane decides and never touches a machine (README); everything in this directory runs on a machine and touches it. These are reference implementations of contracts the control plane defines, and a real one ships with the module that ships the software it configures.

postgres-provisioner the last step of a credential: reads what the mesh delivered and makes PostgreSQL accept it

Running the provisioner

--watch reconciles now and again whenever what the mesh delivered changes. That is what lets it be a module: an ordinary long-running service the host supervises, rather than something that has to be invoked after every declaration by a timer or a unit wired to a file.

It polls rather than watching the filesystem, because the host writes atomically — the file is replaced, so a watch on the path stops seeing anything after the first replacement. A watcher that silently stops working is worse than a poll.

Credentials are compared by digest and never by content. This runs for as long as the machine is up, and a secret does not belong in a long-lived variable when a hash answers the same question.