Name what checks the fork's triggers and track the mirroring question and the missing kept-by (issues 421, 413)

2026-10-10 21:52:00 +02:00
parent b6c592cb9d
commit fb2d5d9f7f
1 changed files with 10 additions and 3 deletions
@@ -101,6 +101,10 @@ The fork is reconsidered at once, with an issue opened, when any of these holds:
 - a security advisory against the pinned release stays unpatched for **30 days**;
 - the image at the pinned digest can no longer be pulled by a node that holds nothing.

+**How this is checked: nothing notices any of the three yet.** A check that pulls every pinned third-party image as
+a node holding nothing would, and watches the object store's upstream for releases and advisories, is tracked by
+issue 421, which is open with no worker. Until it is built, the triggers are read by hand when issue 413 is worked.
+
 ### 2. Garage is the first migration candidate, and it is chosen only after the count

 The first step of any migration is the count: for each consumer of `s3-bucket`, the S3 operations and features
@@ -144,11 +148,13 @@ application's final copy is taken with its writes stopped, in a window the opera
 - No to-be design is written by this record, because no design changes: to-be 07 already says the dependency is on
  the protocol. The design for a migration is written when the count chooses its product, under issue 413.
 - Research 015's open question on mirroring third-party images into the mesh's own registry is not answered
-  here. It remains the open question of issue 113, and it is a general one about every module's images.
+  here. It is a general question about every module's images, and it needs a decision of its own; issue 113,
+  where it was first asked, is resolved, so it is tracked by issue 421 together with the check above.
 - What got harder: nothing moves off the fork without the count, a proven restore point, a check of every object
  and the operator's go twice. That is slower than a copy, on purpose.
 - The gap between the store's declared class (`valuable`) and the photos it holds (`irreplaceable`) stands until a
-  consumer declares `kept-by`; issue 413 tracks it beside the count, because the backup a migration takes is
+  consumer declares `kept-by`. It is tracked by issue 413 beside the count (the issue's second note), and the
+  consumer that keeps the photos declares `kept-by` before a migration starts, because the backup a migration takes is
  sized and kept by that class.

 ## References
@@ -157,7 +163,8 @@ application's final copy is taken with its writes stopped, in a window the opera
  [its comparison](../01-RESEARCH/015-the-object-store-after-minio/01-candidate-comparison.md).
 - [Issue 113](../04-ISSUES/113-the-object-stores-images-were-withdrawn-upstream/00-report.md) and its fix in the
  catalogue's object-store module.
- Issue 413 (the count of S3 features, and any migration), in the issue tracker.
+- Issue 413 (the count of S3 features, the missing `kept-by`, and any migration) and issue 421 (nothing notices a
+  withdrawn image or a silent upstream), in the issue tracker.
 - [ADR 0232](0232-a-binding-to-a-consumers-data-moves-only-by-a-person.md),
  [ADR 0233](0233-a-module-declares-the-data-it-holds-and-the-mesh-protects-and-watches-it-from-that.md),
  [ADR 0236](0236-a-build-is-judged-on-its-first-machine-and-put-back-by-something-other-than-itself-and-so-it-rolls-out-unattended.md).