jschoubben
0ba52d03a3
Nextcloud is the first consumer of two provisions at once: a database from the mesh's postgres and primary storage in a bucket from the mesh's own object store — which is how the arrangement being replaced ran it, minus the bundled MariaDB it no longer needs. Every credential in one env file the host writes; the manifest holds placeholders and the mesh holds nothing readable. Home automation runs on the machine's own network, because discovering devices is the point and a bridge would hide them — so nothing is published, the declared port is the bound port, and the rule set opens exactly it. The case MachineSide was corrected for, in the catalogue. Both pinned by real digests, resolved on this workstation today.
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.