jschoubben
36454d7e4a
A setting overrides a key a contribution or served fact declares and adds none; a provider that must
tell its consumers an operator's value declares it as ${setting:…} (173). The mesh's own files for a
module are a placed directory, `place: "mesh"`, and forty-eight definitions name no host path for
them (174). Registration refuses a definition naming an installation, the day the list emptied
rather than a release later (0155, progressive insight; 134). Designs 27 and 18 carry the rules.
81 lines
5.0 KiB
Markdown
81 lines
5.0 KiB
Markdown
---
|
|
status: resolved
|
|
opened: 2026-09-28
|
|
located-in: [mesh-catalog, mesh-controller internal/catalogue]
|
|
fixed-by: mesh-controller PR 169 (the check, module check, the catalogue-wide test); mesh-catalog PR 188 (the catalogue that passes it); ADR 0155
|
|
amended-design: 03-DESIGN/01-to-be/27-a-module-requires-the-mesh-resolves.md
|
|
---
|
|
|
|
# 134 — A definition may still name the mesh, and the check that would say so does not exist
|
|
|
|
## What was observed
|
|
|
|
[ADR 0112](../../02-DECISIONS/0112-a-module-definition-names-no-node-mesh-or-path.md) 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](../../02-DECISIONS/0111-a-build-source-is-on-the-git-seat-or-external.md)); 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 `why` string 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?
|
|
|
|
## Resolved, 2026-09-30
|
|
|
|
The check exists: `InstallationProblems`, run by `module check` and by a catalogue-wide test. Run over
|
|
the 77 definitions it found 42 values, not 15 — the by-hand count had missed a second name one
|
|
character after the first on the same line, which is the kind of thing a check is for. The three open
|
|
questions: **a domain in a `why` string does not break the rule**, prose is not judged, and the eight
|
|
were rewritten anyway because this catalogue is public; **a service's public name is the name the mesh
|
|
composes for its route**, read through the route's binding, and an operator's own value is a setting;
|
|
**a build context names a repository on the git seat**, `seat: git` with the path, and a context in
|
|
another mesh's forge stays a URL, which the check reports and `names-on-purpose` would declare. The
|
|
seven values that remain are declared with their reason — four applications built outside the mesh —
|
|
and are the list that shrinks ([ADR 0155](../../02-DECISIONS/0155-a-definition-names-no-installation-and-how-that-is-checked.md)).
|
|
Registration does not refuse yet; it will when the list has been empty for a release. *2026-09-30, later the same day:* it refuses — the list was empty the day the check landed, and the operator asked for it (mesh-controller PR 175); `module add` and a build's result are refused in the check's words, with the way out, and the build stays recorded.
|