From c343fc68c5267f23b3d04d8e04f381b7fa227cc4 Mon Sep 17 00:00:00 2001 From: jochen Date: Sat, 26 Sep 2026 15:21:28 +0200 Subject: [PATCH] Issue 108: the second door was attached to the wrong thing MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Two things were treated as one. The mesh's own artifact store holds the store seat and is internal by design — reached by name over the overlay, no accounts, ADR 0082. Serving a registry publicly is a service the mesh can host: a module with its own name, accounts and storage, like anything else it runs for somebody. The conversion this report was written beside gave the seat holder a second public door over the same filesystem, which is neither. Keeps the original issue whole — no garbage collection, and the settings a routine needs are not enabled — drops the two-door complication, and sharpens one thing: deletion on the only door is deletion on a door with no accounts, which the predecessor kept behind its authenticated one. --- .../00-report.md | 29 +++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/04-ISSUES/108-the-registry-has-no-garbage-collection-once-it-has-two-doors/00-report.md b/04-ISSUES/108-the-registry-has-no-garbage-collection-once-it-has-two-doors/00-report.md index feb4a41..74a7709 100644 --- a/04-ISSUES/108-the-registry-has-no-garbage-collection-once-it-has-two-doors/00-report.md +++ b/04-ISSUES/108-the-registry-has-no-garbage-collection-once-it-has-two-doors/00-report.md @@ -8,6 +8,35 @@ amended-design: # 108 — The registry has no garbage collection, and two doors make it harder to add +## 2026-09-26 — the second door was attached to the wrong thing + +*Left in the title and in the text below rather than rewritten, because the reasoning that assumed +two doors is what a reader needs to see retracted.* + +Two separate things were treated as one. **The mesh's own artifact store holds the store seat**: it +is internal, reached by name over the overlay, with no accounts, because being on that network is the +permission ([ADR 0082](../../02-DECISIONS/0082-the-registry-is-reached-by-name-and-trusted-by-the-overlay.md)). +**Serving a registry publicly is a service the mesh can host** — a module with its own name, its own +accounts and its own storage, like any other thing it runs for somebody. The conversion this report +was written beside gave the seat-holding store a second, public, authenticated door over the same +filesystem, which is neither of those: it is the internal store with an external face. + +That second door is not being built. A publicly served registry, if one is wanted, is a module beside +the store rather than another way in to it, and it brings its own storage with it. + +What that leaves here: + +- **The complication in the title is gone.** One door means one registry process on the store's + filesystem, so the shared blob-descriptor cache and the deletion-cached-by-the-other-door problem + this report worried about do not arise at all. +- **The original issue is untouched, and is the whole of it.** The mesh's registry has no garbage + collection, never had, and the settings a collection routine depends on are not enabled. +- **One thing is sharpened rather than removed.** Enabling deletion on the only door enables it on a + door with no accounts, reachable by everything on the overlay. The predecessor kept deletion behind + its authenticated door — which it could, having one. So adding garbage collection now includes + deciding whether deletion is exposed on that door at all, or only ever performed by a routine the + mesh runs against its own store. + ## What was observed Reviewing the conversion that gives the mesh's image registry its public, authenticated name, -- 2.54.0