Issue 108: the registry has no garbage collection, and two doors make it harder to add

2026-09-23 23:32:29 +02:00
parent f6ec64ee4e
commit 73091dcb4c
1 changed files with 48 additions and 0 deletions
@@ -0,0 +1,48 @@
+---
+status: open
+opened: 2026-09-23
+located-in: []
+fixed-by:
+amended-design:
+---
+
+# 108 — The registry has no garbage collection, and two doors make it harder to add
+
+## What was observed
+
+Reviewing the conversion that gives the mesh's image registry its public, authenticated name,
+2026-09-23. The predecessor's registry module ran a maintenance routine on a timer: stop the
+registry, `garbage-collect --delete-untagged`, restart, with a tag-retention step in front. The
+mesh's registry has no such routine — it never did — and the conversion carried the settings the
+routine depends on but not the routine.
+
+The conversion also settled the public door as a **second registry process** on the same
+filesystem, because the store's own door must stay account-free inside the mesh
+([ADR 0082](../../02-DECISIONS/0082-the-registry-is-reached-by-name-and-trusted-by-the-overlay.md)).
+The registry's garbage collector requires every writer stopped while it runs. There are now two.
+Nothing in the mesh's vocabulary says *stop these two containers, run a one-shot against their
+shared volume, start them again*; a `run-once` step runs beside containers, not instead of them.
+
+Meanwhile the merged store holds 53 repositories and every build the mesh will ever make pushes
+another layer set into it. Disk grows without bound.
+
+## Why it matters beyond this instance
+
+A registry without garbage collection is a slow leak that presents as a full disk on a node that
+serves everything else. The predecessor knew this and scheduled for it; the mesh forgot it in the
+conversion because the routine was a script beside the module, not a resource in it — the shape
+[issue 098](../098-taking-a-module-replaces-a-configuration-nobody-compared/00-report.md) describes
+for configuration, here for behaviour.
+
+It also asks something of the module system: a maintenance window over several containers is a
+real thing services need, and the mesh cannot express one.
+
+## Open questions
+
+- Should the module system gain a maintenance step — a one-shot that quiesces named containers,
+  runs, and restores them — or is this better solved by a registry that does not need its writers
+  stopped (a storage backend the mesh does not run today)?
+- Tag retention before GC: the predecessor kept the last N tags per repository; the mesh names
+  images by digest and moves by version — is retention "the digests no recorded build names"?
+- Who owns the routine when the store and its public door are two modules — the store, since the
+  volume is its?