jschoubben
3a92e4b80c
0120 was already accepted; what failed the check was that it rests on 0112, still marked proposed — and so do four designs. The decision stands: a definition names no node, no mesh and no host path, and everything a module needs is a requirement the mesh resolves. Accepting it makes the gap visible rather than hiding it, so issue 134 states it. 0112 says how it is checked — 'a catalogue test finds no domain name in any definition value' — and there is no such test. Asked by hand: seven modules name this installation in a value the mesh acts on, and eight mention a public name in prose nothing reads. The two are not the same fault and the fixes differ, which is why the issue separates them rather than counting to fifteen.
3.4 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | ||
|---|---|---|---|---|---|---|
| open | 2026-09-28 |
|
134 — A definition may still name the mesh, and the check that would say so does not exist
What was observed
ADR 0112 says a module definition names no node, no mesh and no host path, and states how that is checked:
A catalogue test finds no domain name in any definition value.
There is no such test. Run by hand on 2026-09-28, across the 72 manifests in the catalogue, the question it asks has 15 answers. They are not all the same kind of thing, and the difference matters more than the count:
Values the mesh acts on — seven:
| module | where | what it names |
|---|---|---|
| keycloak | env.KC_HOSTNAME |
this installation's public name for itself |
| minio | env.MINIO_BROWSER_REDIRECT_URL |
the same, for its console |
| invoicing | a resource's image |
a named registry rather than the mesh's artifact store |
| builder | build.artifacts[].context.repository |
the forge, by URL |
| route-proxy | build.artifacts[].context.repository |
the forge, by URL |
| route-adapter | a resource's content |
a proxy's dynamic configuration |
| novox.be | module |
the module is named after the domain it serves |
Prose — eight, in listens[].why: de-spiegel, mailu, n8n, only-office, photos, photos-eef,
photos-filip, portainer. Each explains what a port is for and mentions the public name it is reached
by. Nothing reads these; a check written as a string search would report them, and reporting them as
violations of the same rule would be wrong.
Why it matters beyond this instance
An unenforced rule is indistinguishable from a wrong one, and costs more, because people believe it. The record says the mesh is name-agnostic, four design documents rest on that, and a reader checking whether it holds finds that it does not — in the places that matter most. The two forge URLs are what a build reaches into for its source; the two hostnames are what a service tells a browser about itself.
It is the difference between a mesh and this mesh. A definition carrying novox.be is a
definition that can only be installed here. The whole point of the rule is that the same catalogue
raises a different mesh with a different name, and today seven modules would need editing to do it.
And the shape of the fix is not the same for each. A public name is an operator's choice about an assignment, which ADR 0112 already provides for; a forge URL should be a path on the git seat (ADR 0111); an image from a named registry is a question about the artifact store, not about naming. Counting them together would hide that.
Open questions
- Does a domain in a
whystring break the rule? It is documentation the mesh never reads, and a check that cannot tell the two apart will either pass things it should catch or fail things nobody should change. - Where does a service's public name live, concretely — a setting on the assignment, or a fact the mesh composes from the node's domain? ADR 0112 says a requirement the mesh resolves; the two hostnames above are the first real cases.
- Should a build context name a repository on the git seat rather than by URL, and if so, what does that mean for a context in another mesh's forge?