novox/hq
3
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Issue 113 resolved by the repin, and what issue 064 did not cover #108

Merged
jschoubben merged 1 commits from issue/113-record-the-repin-and-fold-114 into main 2026-09-26 12:13:52 +00:00
Conversation 0 Commits 1 Files Changed 1
+24 -2
1 changed files with 24 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit ab7d216fc6 - Show all commits
04-ISSUES/113-the-object-stores-images-were-withdrawn-upstream/00-report.md
+24 -2
View File
@@ -1,8 +1,8 @@
---
status: located
status: resolved
opened: 2026-09-24
located-in: [mesh-catalog modules/minio]
fixed-by:
fixed-by: mesh-catalog — the object-store module repinned to a maintained fork of the withdrawn server image, its runtime sidecar built from source rather than pulled, and its data moved off the predecessor's live directory. The standing condition this report names is not closed by it — see What was done.
amended-design:
---
@@ -109,6 +109,28 @@ a registry the mesh does not control — **by tag or by digest, it makes no diff
dependency with no guarantee behind it, and the mesh currently learns it has lost one only by
trying to use it.
[Issue 064](../064-a-mesh-build-cannot-fetch-a-modules-external-dependencies/00-report.md) is the
nearest precedent, and it does not cover this. That issue asked whether the mesh's build
environment can **reach** a declared vendor image — a network-policy question, answered by
requiring the image be declared as a build input — and it assumed that an image, once declared,
stays fetchable. Withdrawal is the case the assumption does not cover: no network policy and no
declaration makes a deleted repository resolvable, so a module can satisfy 064 in full and still
be unbuildable on a node that holds nothing.
## What was done
The module was repinned to a maintained fork of the server image, published to a registry that
still serves it; its runtime sidecar is now built from source rather than pulled; and its data was
moved off the predecessor's live directory. The object store runs on the control-node from that
pin, and a node holding nothing can obtain it again.
That answers the instance and none of the three points above. The mesh still cannot say which of
its other pinned third-party images are still obtainable, and it would still learn of a withdrawal
only when a node without the image tried to deploy. The replacement question — S3 the protocol
rather than this product — is carried by
[research 015](../../01-RESEARCH/015-the-object-store-after-minio/00-overview.md); the detection
question is carried by nothing, and is the first of the open questions below.
## Open questions
- Should the mesh **hold** the images it depends on — mirroring third-party images into its own