61 lines
3.1 KiB
Markdown
61 lines
3.1 KiB
Markdown
---
|
|
status: resolved
|
|
opened: 2026-10-04
|
|
located-in:
|
|
- mesh-host
|
|
fixed-by:
|
|
- mesh-host#87
|
|
amended-design:
|
|
---
|
|
|
|
# 223 — A new mesh installs its controller as a container
|
|
|
|
## What was observed
|
|
|
|
2026-10-04. Preparing [issue 213](../213-the-controller-is-a-go-program-run-in-a-container/00-report.md),
|
|
the controller's own manifest was changed to a Go bundle run as a process. The installer that raises a
|
|
new mesh assumes the controller is an image and a container at every step from its third on:
|
|
|
|
- it requires the controller's build to produce exactly one image;
|
|
- it starts a temporary controller from that image, and publishes the image to the registry;
|
|
- at the pivot, it finds the controller's container in the declaration, reads its environment and
|
|
volumes, waits for it, and from then on talks to the controller only through the container.
|
|
|
|
## Why it matters beyond this instance
|
|
|
|
With the controller's manifest changed, a new mesh cannot be installed: the pivot fails. The deeper
|
|
constraint is ordering. A process's bundle is fetched from the artifact store, and the installer
|
|
raises the artifact store only after the pivot, so the controller's first declaration names a bundle
|
|
nothing can serve yet.
|
|
|
|
## What a fix has to settle
|
|
|
|
One of two shapes, and it is a decision, not a repair:
|
|
|
|
1. raise the artifact store before the pivot, publish the controller's bundle to it, and talk to the
|
|
controller from the host's side rather than through a container; or
|
|
2. pivot to the image form as today, and let the first push hand over to the process, which
|
|
requires the controller's manifest to carry both forms.
|
|
|
|
Until it is settled, the change of the controller's manifest (mesh-controller#253) is held. The
|
|
handover itself is built and merged (mesh-host#86); the controller's half (mesh-controller#252) waits
|
|
on the operator. **How it is checked:** the installer's test raises a mesh whose controller manifest
|
|
is the process form, and the controller answers its seat's verbs at the end.
|
|
|
|
## Decided (2026-10-04)
|
|
|
|
Option 2, [ADR 0200](../../02-DECISIONS/0200-genesis-pivots-to-the-controller-as-a-container-and-the-first-push-hands-it-to-a-process.md):
|
|
genesis pivots to the controller as a container recorded under the name the process `replaces`, and
|
|
the first push hands it over.
|
|
|
|
## Resolved
|
|
|
|
Built as [ADR 0200](../../02-DECISIONS/0200-genesis-pivots-to-the-controller-as-a-container-and-the-first-push-hands-it-to-a-process.md)
|
|
decided: genesis reads only the controller's process from the manifest, builds the controller's image
|
|
from its repository, and pivots to a container of its own shape recorded under the id the process
|
|
`replaces`; an older controller in the image form still builds as before. **How it is checked:** the
|
|
installer's tests build the genesis form from the controller's real manifest, and apply the
|
|
controller's first process declaration over the recorded container with the host's own apply — the
|
|
process starts, the container is removed, one controller remains. A real install from nothing has not
|
|
been run since; the handover it ends in was proven live on the running mesh (issue 213).
|