jschoubben
ee3cc1b6f4
novox/hq 04-ISSUES/025. Every image reference in every example module was sixty-four zeros — eighteen of them across five modules. Each parsed, resolved, and composed into a declaration a host accepts, and none could ever have started: the machine reaches `docker pull` and stops. That is why those modules were written and not running, and no check saw it because every check passed. The host validates the shape of a reference and nothing more, which is correct: verifying a digest exists means reaching a registry, and that is the one thing a host must never have to do. So the last place that could catch this is the wrong place to try. The guard therefore sits where a declaration is composed, not where a manifest is parsed. A file in a repository is allowed to await a pin — the design already says the manifest in a repository names artifacts while the manifest the mesh holds names digests, and the bundle works exactly that way. What must never happen is a placeholder reaching a machine, and composing is the last moment before one does. Twelve third-party images resolved to real digests without pulling anything, which is also the mechanism the open issue needs. Two discoveries came free: mailu publishes to ghcr rather than Docker Hub, so seven references named repositories that do not exist at all; and it renamed roundcube to webmail, so that one would have failed even with the right registry. What stays a placeholder is the mesh's own provisioner images, which genuinely have no digest until built and pushed — the bundle's problem, legitimately unresolved here. The stand-in consumer now stands in with a real image rather than an invented one.
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.