jschoubben
a2542e51f8
Filed as a to-do. Nothing is broken by it: every machine here is amd64 and reports so, and one architecture is enough for now. When a machine joins, the mesh should collect what it reasonably can about it and refresh that daily. It already asks what a machine can do; what it is made of is the same question one level down. More is already collected than it looks — eight capabilities, the links that face outside, the host version, and on an adopted machine what it holds, what is reachable and the firewall and tunnel it was found with. The architecture and the kernel are in there too, and nothing reads either: measured, all four machines report amd64 and linux, and node show prints the capabilities beside them without printing them. Missing: memory, disk, the processor beyond its architecture, the distribution and its version, virtual or physical, cores, uptime. Several are what somebody wants when deciding where a module goes, and the placement code's own comment already imagines them. Also missing: the refresh. A machine publishes after an apply, and the five-minute reconcile publishes nothing, so the mesh's picture is as old as the last push. Same mechanism 087 wanted. This is the third thing in one day found to be collected and read nowhere, after held resources and the host version. Whatever gets added should say in the same breath which surface shows it, or it will be the fourth. 159 gains the note that the architecture is already reported, so matching an artifact to a machine needs no new fact — only the comparison and a compiler told what to target.
101 lines
4.8 KiB
Markdown
101 lines
4.8 KiB
Markdown
---
|
|
status: located
|
|
opened: 2026-09-30
|
|
located-in:
|
|
- mesh-controller internal/catalogue/build.go (System is validated and read by nothing else)
|
|
- mesh-controller internal/builder (the compile invocation names no target)
|
|
fixed-by:
|
|
amended-design:
|
|
---
|
|
|
|
# 159 — An artifact's system is checked, and then nothing uses it
|
|
|
|
## What was observed
|
|
|
|
Asked whether the host is built for more than one architecture, 2026-09-30, having just built it
|
|
through the new Go toolchain.
|
|
|
|
[ADR 0142](../../02-DECISIONS/0142-the-mesh-delivers-its-own-components-as-binaries.md) says an
|
|
artifact declares what it targets, and that one artifact per target is one build each. The manifest
|
|
layer enforces the first half strictly: a bundle in a language that compiles to a binary **must** name
|
|
a system, must name one of `alpine`, `android`, `arch`, and must not name one at all if its language is
|
|
interpreted. A manifest that gets any of that wrong is refused with a reason.
|
|
|
|
**The field is then read by nothing.** Every use of it in the control plane is in the function that
|
|
validates it. It does not reach the compiler, no machine is matched against it, and nothing chooses
|
|
between two artifacts by it.
|
|
|
|
So the compile runs with no target named and produces a binary for whatever the build machine happens
|
|
to be. The host, declared `system: arch` and built on this mesh's only build machine:
|
|
|
|
```
|
|
mesh-host: ELF 64-bit LSB executable, x86-64, statically linked, stripped
|
|
```
|
|
|
|
Correct for every machine in this mesh, which are all x86-64 Arch — and correct by coincidence rather
|
|
than by anything the declaration did.
|
|
|
|
## Why it matters
|
|
|
|
**A module declaring two systems would get two identical binaries.** Both would be published, both
|
|
pinned, both delivered, and the one sent to the machine it was not built for would fail at exec with a
|
|
message about a format — which is the shape ADR 0005's link-time pin exists to prevent, arriving
|
|
because the pin was never applied.
|
|
|
|
`android` in the list is the sharp end: it is not an x86-64 platform, and an artifact declared for it
|
|
today would be an x86-64 binary wearing the label. Nothing would say so until a machine tried to run
|
|
it.
|
|
|
|
**And the field reads as implemented.** It is required, validated against a closed list, and refused
|
|
with a careful message — every signal a manifest author gets says the mesh is acting on it. A field
|
|
that is checked and ignored is worse than one that does not exist, because the check is what persuades
|
|
you it works.
|
|
|
|
## Two things this is not
|
|
|
|
- **Not the same axis as the distribution.** `alpine`, `android`, `arch` are what a machine reports
|
|
itself to be, and the comment on the list says why: "the difference between two of them is a C
|
|
library, not a kernel". The processor is a second dimension and the manifest has no word for it at
|
|
all — so even a correct implementation of the current field would not answer the question that
|
|
started this.
|
|
- **Not urgent for this mesh.** Four machines, all x86-64 Arch, one build machine. Nothing is broken
|
|
today and nothing will be until a machine differs — which is exactly how long a field like this stays
|
|
invisible.
|
|
|
|
## The machine already says what it is
|
|
|
|
Found while filing [issue 160](../160-a-machine-says-little-about-itself-and-only-when-asked/00-report.md):
|
|
every machine reports its architecture and kernel in the same profile that carries its capabilities, and
|
|
the mesh keeps them.
|
|
|
|
```
|
|
ace | amd64 | linux
|
|
g14 | amd64 | linux
|
|
novox | amd64 | linux
|
|
shanks | amd64 | linux
|
|
```
|
|
|
|
Nothing in the control plane reads either, and `node show` prints the capabilities beside them without
|
|
printing them. **So a fix does not need a new fact from the machine** — matching an artifact's declared
|
|
system against what a machine reported is possible today, and the missing piece is only the comparison
|
|
and a compiler told what to target.
|
|
|
|
## Where to look
|
|
|
|
The compile invocation is assembled in `mesh-controller internal/builder`, and for Go it would need
|
|
`GOOS`/`GOARCH` set from the artifact rather than inherited from the build machine. That needs the
|
|
manifest to carry a processor as well as a system, or the systems list to mean both — which is a
|
|
decision, not a fix, and belongs with whoever answers whether one static binary should serve several
|
|
distributions at all.
|
|
|
|
**That last question is live.** The Go toolchain builds statically, so a single binary has no C library
|
|
to differ about and would in fact run on Alpine and Arch alike. The per-system pin is then a policy — a
|
|
host refuses a machine it was not built for — rather than a technical necessity, and worth knowing is a
|
|
choice.
|
|
|
|
## How a fix is checked
|
|
|
|
An artifact declared for a system the build machine is not produces a binary for that system, shown by
|
|
reading the file rather than by the build reporting success; and two artifacts declared for two systems
|
|
do not have the same digest.
|