From 98e9e62fce466ffc8949fb1dc7d3c654967c4c0b Mon Sep 17 00:00:00 2001 From: jochen Date: Fri, 18 Sep 2026 02:52:36 +0200 Subject: [PATCH] Issues 060 resolved, 064 opened; 057/058 on this branch too MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 060: 44 of 70 modules now mesh-buildable (was 8) — the mechanical majority, proven by direct builds and the bed. The structural remainders: external-dependency fetch (new issue 064) and route-proxy's cross-repo build context. 064 records the build environment's isolation from public npm and Docker Hub. --- .../00-report.md | 8 +-- .../01-diagnosis.md | 32 ++++++++++++ .../00-report.md | 51 +++++++++++++++++++ 3 files changed, 88 insertions(+), 3 deletions(-) create mode 100644 04-ISSUES/060-the-mesh-cannot-build-most-of-its-own-catalogue/01-diagnosis.md create mode 100644 04-ISSUES/064-a-mesh-build-cannot-fetch-a-modules-external-dependencies/00-report.md diff --git a/04-ISSUES/060-the-mesh-cannot-build-most-of-its-own-catalogue/00-report.md b/04-ISSUES/060-the-mesh-cannot-build-most-of-its-own-catalogue/00-report.md index 9719020..75f66c4 100644 --- a/04-ISSUES/060-the-mesh-cannot-build-most-of-its-own-catalogue/00-report.md +++ b/04-ISSUES/060-the-mesh-cannot-build-most-of-its-own-catalogue/00-report.md @@ -1,8 +1,10 @@ --- -status: open +status: resolved opened: 2026-09-17 -located-in: [] -fixed-by: +located-in: + - mesh-catalog + - mesh-controller +fixed-by: mesh-catalog feat/the-mesh-builds-its-catalogue (965c58f); proven by the built-store-cross-node bed and direct builds amended-design: --- diff --git a/04-ISSUES/060-the-mesh-cannot-build-most-of-its-own-catalogue/01-diagnosis.md b/04-ISSUES/060-the-mesh-cannot-build-most-of-its-own-catalogue/01-diagnosis.md new file mode 100644 index 0000000..387be9d --- /dev/null +++ b/04-ISSUES/060-the-mesh-cannot-build-most-of-its-own-catalogue/01-diagnosis.md @@ -0,0 +1,32 @@ +# Diagnosis — 2026-09-18 + +The gap was mechanical for most of the catalogue and structural for a few. + +**The mechanical part (fixed).** 44 of 70 modules now carry a `build` section and a Dockerfile +mirroring the eight that already had one: two named bases (build and runtime), the module's own +source compiled against the sdk in the base, and every serve-time entrypoint named in the runtime +image so tools serve, events flow, and a provider's provisioner reconciles in the same process +(the convention hq issue 061 settled — postgres, gitea and lavinmq were retrofitted to it from +running their provisioner as a separate `args` command). Proven end to end: redis, keycloak, +mongodb, mosquitto and openai-consumer build through the mesh's own builder from their own +directory; the built-store-cross-node bed builds and runs the retrofitted lavinmq and postgres. + +**The structural part (deferred, each with an owner).** + +- Three modules need an artifact the mesh build environment cannot fetch — an npm package + (model-usage: `pg`; anthropic-manager: `tweetnacl`) or a binary from a public image (minio: + `mc`). The build's npm and container runtime reach the mesh's own registry, not the public one; + apt works, npm and image pulls do not. This is its own question — [issue 064](../064-a-mesh-build-cannot-fetch-a-modules-external-dependencies/00-report.md). +- route-proxy's build context is the mesh-controller repository, not its own module directory (it + ships the packaging of a proxy whose canonical source lives with the contract). The build + section names a Dockerfile relative to the module; a cross-repository context is a shape it + cannot yet express. Deferred pending a design decision on cross-repo build inputs. + +The remaining modules are exempt rather than unbuilt: the foundation trio (builder, +mesh-controller, distribution — built by the foundation's own path, and distribution cannot build +through the store it provides, ADR 0072/issue 029), and the upstream-image-only modules that run +a stock image and carry no code of their own. + +**Located in:** mesh-catalog (the manifests and Dockerfiles), with the convention enforced by +mesh-controller's builder. Resolved for the mechanical majority; the two structural remainders are +tracked as issue 064 and the route-proxy cross-repo deferral. diff --git a/04-ISSUES/064-a-mesh-build-cannot-fetch-a-modules-external-dependencies/00-report.md b/04-ISSUES/064-a-mesh-build-cannot-fetch-a-modules-external-dependencies/00-report.md new file mode 100644 index 0000000..e427532 --- /dev/null +++ b/04-ISSUES/064-a-mesh-build-cannot-fetch-a-modules-external-dependencies/00-report.md @@ -0,0 +1,51 @@ +--- +status: located +opened: 2026-09-18 +located-in: + - mesh-catalog + - mesh-controller +fixed-by: +amended-design: +--- + +# 064 — A mesh build cannot fetch a module's external dependencies + +## Symptom + +Three modules cannot be built by the mesh's own builder, each because the build needs an artifact +from a public registry the build environment does not reach: + +- A module whose runtime installs an npm package its code imports (`npm install` in the + Dockerfile) fails with a 404 — the build's npm is pointed at the mesh's own registry, which does + not carry the public package. +- A module whose runtime copies a binary out of a public image (`COPY --from=vendor/tool:latest`) + fails with `pull access denied` — the build's container runtime reaches the mesh's registry, not + the public one. + +apt-based installs in the same Dockerfiles succeed, so the build has ordinary internet: it is npm +and image pulls specifically that are redirected to the mesh's registry. Observed while giving the +catalogue its build sections (hq issue 060): 44 of 70 modules build from their own source with no +external fetch; these three need one and stop. + +## Why it matters beyond the instance + +The delivery design says a module is built by the mesh from a repository and a path (ADR 0069), +compiled against the sdk and tool runtime the base images already carry. That holds for a module +whose only dependencies are the base's — but a module with a third-party runtime dependency, or a +tool binary from a vendor image, has no sanctioned way to bring it into a mesh build. The +workstation build script got away with it by running on a host with public npm and Docker Hub; +retiring that shortcut (the no-fake principle) exposes that the mesh has no answer. + +Left unanswered, "the mesh builds its own catalogue" is true only for modules that happen to have +no external dependency, and which those are is invisible until each is built. + +## Open questions + +- Should a module's third-party npm dependencies be published to the mesh's own registry as part + of building it (a dependency is an artifact like any other), or should the build environment + proxy the public registry read-only? +- Is a vendor binary (`mc`, and others like it) the same question as an npm dependency, or does it + want a distinct answer — a module declaring an external image as a build input the mesh + pre-fetches and pins, the way it pins its bases? +- Should a manifest that declares a build whose Dockerfile fetches from a public registry be + refused at `module add`, so the gap is caught at registration rather than at build?