From 087a8f4144f580cceec0ae9f67836cfc94e0d4d4 Mon Sep 17 00:00:00 2001 From: jochen Date: Sat, 29 Aug 2026 00:05:20 +0200 Subject: [PATCH] Close 009: a sealed machine now pulls by digest The resolution was the one the issue predicted -- a registry inside the scenario -- and it is the real path rather than a stand-in, since that is what every node after the first pulls from. The digests are the lab registry's own, which satisfies the pinning rule: what is required is a reference that is exact and cannot move, and one this registry assigned is both. That was the insight that unblocked it; I had assumed the upstream digest had to be preserved, which is what made it look impossible. The fault worth keeping is recorded in the issue: the read-back checked that the catalog endpoint answered by matching the substring 'repositories', which an empty catalog also contains. It passed on a registry holding nothing. This repository's own subject, arriving in the tooling built to catch it. --- .../00-report.md | 28 ++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/04-ISSUES/009-a-digest-pinned-image-cannot-be-placed-in-the-lab/00-report.md b/04-ISSUES/009-a-digest-pinned-image-cannot-be-placed-in-the-lab/00-report.md index 94f0bca..b90a554 100644 --- a/04-ISSUES/009-a-digest-pinned-image-cannot-be-placed-in-the-lab/00-report.md +++ b/04-ISSUES/009-a-digest-pinned-image-cannot-be-placed-in-the-lab/00-report.md @@ -1,8 +1,9 @@ --- -status: open +status: fixed opened: 2026-08-28 located-in: [mesh-lab, mesh-host] fixed-by: + - "mesh-lab: a registry raised inside the scenario. Verified in a sealed machine — all four shapes applied with the image pinned by digest, idempotent, read back from the machine." amended-design: --- @@ -63,6 +64,31 @@ a container ([`07-the-substrate.md`](../../03-DESIGN/01-to-be/07-the-substrate.m bootstrap cannot be tested end-to-end until this is resolved — which is the thing the lab exists for. +## How it was fixed + +*2026-08-29.* A registry inside the scenario, as below — and it turned out to be the shape the +resolution predicted rather than a compromise on it. + +A scenario declares `images:` by tag. The lab stocks a registry **on the workstation**, where +there is a network, then raises one **inside the scenario** as scenery and serves them from it. +What a declaration pins is reported when the scenario is raised, because the digest belongs to +that registry and is not knowable before it exists. + +**The digests are the lab registry's own, and that is correct rather than a workaround.** What +[ADR 0006](../../02-DECISIONS/0006-the-substrate-and-the-control-plane.md) requires is a +reference that is exact and cannot move. A digest this registry assigned is both. + +Verified in a machine confirmed to have no route out: `package`, `service` including boot state, +a `container` pinned by digest, and an `action` inside that container — applied, idempotent on +re-apply, and read back from the machine rather than from the apply's own report. + +**One fault is worth keeping**, because it is this repository's own subject arriving in the +tooling built to catch it. The read-back checked that the registry's catalog endpoint answered, +by looking for the substring `repositories` — which `{"repositories":[]}` also contains. So it +**passed on a registry holding nothing**, and the failure surfaced much later as a container that +could not be pulled, a long way from its cause. It now asks for each image's manifest **by +digest**, which is what a machine actually does. + ## The shape of a resolution **A registry inside the scenario**, on its public segment, that machines pull from. That is not a