Files
hq/04-ISSUES/046-an-upstream-image-cannot-be-mirrored-into-the-mesh/01-diagnosis.md
T

20 lines
1.4 KiB
Markdown

# Diagnosis — 2026-09-21
1. What was established stands: the failure is in going through a machine's image store, whose
newer store keeps an index and refuses to push a single platform out of it. Every variant of
pull-then-push was tried and failed the same way.
2. The first open question answers the other two. A copy between registries never needs a
platform, because it moves what is there — the index and every manifest it names, or one
manifest if the module says so. The registry API is enough for it: read the index, read each
manifest, mount or upload each blob by digest, put the manifests and then the index under the
module's repository. No image store is involved and the runtime's behaviour stops mattering.
3. Whether the mesh mirrors an index or a platform is then a choice the copy can offer rather
than a limitation; today every machine on one mesh is the same architecture, and that
assumption is now written down here rather than nowhere.
**Located in:** the builder's upstream-artifact step. Fixed as
[ADR 0096](../../02-DECISIONS/0096-an-upstream-image-is-copied-between-registries.md): a copy over
the registry API, proven against a fake upstream serving an index over two platforms behind a
bearer challenge. A run against the public hub from a mesh's builder is the remaining proof, and
the first build of a module with an upstream artifact will be it.