jschoubben
013dbce4a9
Installing the module that provides `artifact-store` requires something that provides `artifact-store`: its image is mirrored in, mirroring publishes to the store, and the builder refuses to run without one. Never seen, because the lab always has a registry standing before the mesh asks for one, and so does any mesh built on a machine that already had one. What it blocks is larger than a registry. The store holds images and packed archives both — it is the module catalogue in artefact form — so until it exists a mesh can run only what its bundle already carries. The substrate record already answers it. It asks of each candidate whether it can grant itself the thing it provides: the store cannot create its own database, the broker cannot create its own virtual host, and the registry cannot grant itself a repository. So the registry module names its image and is never built. With a limit worth saying out loud rather than discovering: a module providing the store may not build artifacts of its own, a UI or a tool server included, because there is nowhere to put them until it runs. Such a registry is two modules.
4.0 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | |
|---|---|---|---|---|---|
| open | 2026-09-01 |
|
029 — The artifact store cannot be delivered by the artifact store
Symptom
A mesh that has just bootstrapped cannot install a registry. The module describing one resolves, composes and pushes; the build never completes, because there is nowhere to put what it builds.
It has never been seen, because the lab always has a registry standing before the mesh asks for one, and so does any mesh built on a machine that already had one.
What it actually blocks
Not "a registry cannot be installed" — a mesh cannot hold its own modules.
The artifact store is one store for everything a module ships: images, and archives, which are directories from a module's repository packed and pushed as content-addressed blobs. So it is the mesh's module catalogue in artefact form, and the same role a separate object store plays in the arrangement being replaced.
Until it exists, a module can be described and resolved but nothing it carries can be kept anywhere. A mesh that has just bootstrapped can therefore run only what its bundle already holds.
The cycle
Three facts, each correct on its own:
- A registry module's image is mirrored in.
kind: upstreampulls the reference the module names and pushes it under a name of the mesh's own, so what a machine fetches is pinned by a digest this mesh assigned rather than by a tag somebody else can move. - The builder publishes to the artifact store, learned from its
artifact-storebinding — the same binding any consumer of any provision gets. - The builder refuses to run without one: "a built artifact nobody can fetch is not built."
So installing the thing that provides artifact-store requires something that provides
artifact-store.
Why the design already answers it
The substrate record asks of each candidate can it grant itself the thing it provides? The store cannot create its own database; the broker cannot create its own virtual host; and the registry cannot grant itself a repository. That is why the registry is substrate by role.
The same sentence answers this. A module that provides the artifact store cannot be delivered through the artifact store, so its image is not the mesh's to mirror — it is named directly and pulled from upstream exactly once, which is what the bundle already does for the three images a first node starts from.
The fix
The registry module names its image, and is never built. A container naming
registry@sha256:… needs no builder, no binding and no store. Every module after it mirrors
normally, into the registry now running.
Nothing new is required: naming an image directly is what most modules do.
What it costs, and what it does not
The machine running the first registry needs to reach a public registry once, to pull that one image by digest. That is already true of a first node, which fetches three images the same way before a mesh exists.
It does not weaken pinning. A digest is exact wherever it came from; what mirroring adds is that the mesh keeps its own copy and does not depend on a tag somebody else controls. For one image, on one machine, once, the bundle already accepts that trade and says why.
The constraint this puts on a registry module
A module providing artifact-store may not build artifacts of its own — not its image, and
not a user interface or a tool server shipped beside it. There is nowhere to put them until it is
running.
A registry that wants more than the upstream image is therefore two modules: one that provides the store and only names an image, and an ordinary module beside it that builds whatever else and mirrors it in the normal way. That is a real limit on how a registry module can be written, and it should be said out loud rather than discovered.
How it is checked
A manifest that both provides artifact-store and declares built artifacts is refused where it is
written, naming the cycle. Otherwise the fault surfaces as a build that never returns, on a mesh
too new to have anybody watching it.