Genesis registers the control plane with the manifest its build produced (hq issue 072) #17

2026-09-21T13:27:43Z

jschoubben commented

2026-09-21 13:27:43 +00:00

What

The control plane's manifest existed twice: at the root of its repository (read whenever the mesh rebuilds it from source) and as a copy in the catalogue (read by genesis at step 9). Nothing kept them equal; the first rebuild replaced the mesh's record with the repository's shape and every later push was refused (hq issue 072). ADR 0069 had already placed the manifest in the controller's repository.

Step 3 (BuildControlPlane) keeps the manifest the builder's one-shot result already reports — the repository's, artifact resolved to the built image — and refuses a result without one or whose manifest does not name the built image.
Step 9 (InstallControlPlane) registers that manifest, re-pinning the built image's bare sha256: id to the reference the registry assigned. It reads nothing from the catalogue any more.
The builder module still comes from the catalogue and still pins a placeholder; that path is now pinPlaceholder, unchanged. --catalog docs say what it is still for.

Proven

go test ./... green (new tests: the build hands over the manifest; no manifest / another image refused; pinning moves the whole reference, every place). genesis-single bed green in the lab against this branch with a catalogue holding no modules/mesh-controller (mesh-catalog MR on the same branch name), receipt against mesh-host 5223169, mesh-controller 69d0b94:

build — the control plane, from its own repository and a commit
  built mesh-controller from 69d0b943
control plane — installed as an ordinary module, pinned to that digest
  pinned            sha256:d… → 127.0.0.1:5000/mesh-controller@sha256:de5085a5…, in 1 place(s)
  registered        mesh-controller

Companion MRs on feat/one-controller-manifest: mesh-catalog (the copy deleted), mesh-lab (genesis expects distribution + builder), hq (072 diagnosed, design 17 amended).

## What The control plane's manifest existed twice: at the root of its repository (read whenever the mesh rebuilds it from source) and as a copy in the catalogue (read by genesis at step 9). Nothing kept them equal; the first rebuild replaced the mesh's record with the repository's shape and every later push was refused (hq issue 072). ADR 0069 had already placed the manifest in the controller's repository. - Step 3 (`BuildControlPlane`) keeps the manifest the builder's one-shot result already reports — the repository's, artifact resolved to the built image — and refuses a result without one or whose manifest does not name the built image. - Step 9 (`InstallControlPlane`) registers that manifest, re-pinning the built image's bare `sha256:` id to the reference the registry assigned. It reads nothing from the catalogue any more. - The builder module still comes from the catalogue and still pins a placeholder; that path is now `pinPlaceholder`, unchanged. `--catalog` docs say what it is still for. ## Proven `go test ./...` green (new tests: the build hands over the manifest; no manifest / another image refused; pinning moves the whole reference, every place). genesis-single bed green in the lab against this branch with a catalogue holding no `modules/mesh-controller` (mesh-catalog MR on the same branch name), receipt against mesh-host 5223169, mesh-controller 69d0b94: ``` build — the control plane, from its own repository and a commit built mesh-controller from 69d0b943 control plane — installed as an ordinary module, pinned to that digest pinned sha256:d… → 127.0.0.1:5000/mesh-controller@sha256:de5085a5…, in 1 place(s) registered mesh-controller ``` Companion MRs on `feat/one-controller-manifest`: mesh-catalog (the copy deleted), mesh-lab (genesis expects distribution + builder), hq (072 diagnosed, design 17 amended).

jschoubben added 2 commits 2026-09-21 13:27:43 +00:00

Genesis registers the control plane with the manifest its build produced 5223169226

The control plane's manifest existed twice: at the root of its repository, read
whenever the mesh rebuilds it from source, and as a copy in the catalogue, read by
genesis. Nothing kept them equal, and the first rebuild replaced the mesh's record
with the repository's shape while every later push was refused (novox/hq
04-ISSUES/072). The builder's one-shot result already carries the manifest it built,
artifact resolved to the image; step 3 keeps it and step 9 registers it, re-pinning
the built image's bare id to the reference the registry assigned. The catalogue is
still read for the registry's and the builder's manifests and for phase two.

The pinning line shows the built image's id, not one digit of it 8afbe57814

jschoubben added 1 commit 2026-09-21 17:21:06 +00:00

Step 9 without a build is refused, and a test says so ffe7dbd348

jschoubben merged commit e8b6d9ac31 into main

2026-09-21 17:23:18 +00:00

jschoubben deleted branch feat/one-controller-manifest

2026-09-21 17:23:18 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: novox/mesh-host#17