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.
4.8 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | ||
|---|---|---|---|---|---|---|
| located | 2026-09-30 |
|
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 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,archare 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: 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.