From 24d52a8380cad6e25c886131d6c61191d3f74768 Mon Sep 17 00:00:00 2001 From: jochen Date: Mon, 14 Sep 2026 13:27:42 +0200 Subject: [PATCH] =?UTF-8?q?Issue=20046=20=E2=80=94=20an=20upstream=20image?= =?UTF-8?q?=20cannot=20be=20mirrored=20into=20the=20mesh's=20registry?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Found while migrating the first module. Five approaches were tried and observed to fail, including resolving the index and naming the platform at both ends; a speculative fix was written and reverted rather than shipped, because it did not make the mirror work. One module uses this today, which is why it went unnoticed — and it is the shape most of a migration wants, because the services being moved are third-party. --- .../00-report.md | 69 +++++++++++++++++++ 1 file changed, 69 insertions(+) create mode 100644 04-ISSUES/046-an-upstream-image-cannot-be-mirrored-into-the-mesh/00-report.md diff --git a/04-ISSUES/046-an-upstream-image-cannot-be-mirrored-into-the-mesh/00-report.md b/04-ISSUES/046-an-upstream-image-cannot-be-mirrored-into-the-mesh/00-report.md new file mode 100644 index 0000000..74ee275 --- /dev/null +++ b/04-ISSUES/046-an-upstream-image-cannot-be-mirrored-into-the-mesh/00-report.md @@ -0,0 +1,69 @@ +--- +status: open +opened: 2026-09-14 +located-in: [] +fixed-by: +amended-design: +--- + +# 046 — An upstream image cannot be mirrored into the mesh's own registry + +## Symptom + +A module may declare that one of its artifacts is an image published elsewhere, to be copied into +the mesh's own registry so machines fetch it by a digest this mesh assigned rather than by a name +somebody else controls. Asking for such a module fails: + +``` +docker push //: exit status 1 +image with reference …:latest was found but does not provide any platform +``` + +Nothing reaches the registry — its log has no entry for the attempt at all. + +## Why this matters + +**It is the only way a third-party image becomes the mesh's own.** Everything else a module can do +with an image names it where it lives, so every machine fetches it from the internet, separately, +for ever, and by whatever that name points at on the day it asks. Mirroring is what makes an image +a thing the mesh holds and can speak about — and it is the shape most of a migration would want, +because the services being moved are overwhelmingly third-party. + +Today exactly one module uses it, so nothing is broken that was working. That is also why it went +unnoticed. + +## What was established + +Each of these was tried and observed, not assumed: + +- The image named is an **index over several architectures**, which is what a published image + ordinarily is and what a module sensibly writes down. +- Fetching it leaves *the index* in the runtime's store. Asking about it reports a resolved + operating system and architecture while still holding the index, so inspecting it looks fine. +- **Asking for a platform at fetch time does not help.** The store still holds the index. +- **Resolving the index first does not help either.** The runtime will name the one manifest for + this architecture, and fetching *that digest specifically* still leaves something the registry + refuses, with the same message. +- **Nor does naming the platform at push time.** The message changes to `does not provide the + specified platform (linux/amd64)` — for the platform that was just fetched by its own digest. +- The tooling that exists to copy images between registries without any of this is not present on + the machine, and the runtime's own suggestion — push one platform — is the thing that fails. + +A speculative fix along those lines was written, tested, and **reverted**: it did not make the +mirror work, and leaving machinery that resolves indexes without achieving what it was added for +would be complexity plus a comment claiming something untrue. + +## How it would be checked + +A module declaring an upstream artifact is asked for, and the mesh's registry serves what it named +under the module's own repository. Today that check fails at the push, which is where it should +be checked from: the registry either serves it or it does not. + +## Open questions + +- Is copying between registries the right shape here, rather than going through a machine's image + store at all? A copy never needs a platform, because it moves what is there. +- Should the mesh mirror an index or a platform? Every machine on one mesh being the same + architecture is an assumption that holds today and is not stated anywhere. +- Is this the runtime's newer image store specifically? Worth knowing before working around it, + because a workaround for a behaviour that is itself a bug is a thing nobody removes later.