A machine says little about itself, and only when the mesh asks it something

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.
2026-09-30 10:36:40 +02:00
parent b19b29cd3a
commit a2542e51f8
2 changed files with 110 additions and 0 deletions
@@ -62,6 +62,24 @@ you it works.
  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
@@ -0,0 +1,92 @@
 ---
 status: open
 opened: 2026-09-30
 located-in:
  - mesh-host internal/profile (what a machine collects about itself)
  - mesh-controller internal/inventory (what the mesh keeps of it)
  - mesh-controller cmd/mesh-controller (node show, which displays a part of it)
 fixed-by:
 amended-design:
 ---
 # 160 — A machine says little about itself, and only when the mesh asks it something
 *Filed as a to-do rather than a fault: nothing is broken by it today. `open` is the status this
 repository has for "written down, nobody has started" — there is no `todo`.*
 ## What is wanted
 **When a machine joins, the mesh should collect as much as it reasonably can about it**, and refresh
 that daily or thereabouts. It already asks what the machine *can do*; what it is made of is the same
 question one level down, and the mesh has no habit of asking it.
 ## What is already collected, which is more than it looks
 A machine reports, and the mesh keeps:
 | | |
 |---|---|
 | eight capabilities | container-runtime, firewall, graphical-session, overlay, package-manager, privileged, seat, service-manager — each with a version or a reason it is absent |
 | **its architecture and kernel** | in the same profile, beside the capabilities |
 | which links face outside it | read from its own routing table on every apply |
 | the version of the host running on it | added 2026-09-30 |
 | what it found and is holding | on an adopted machine |
 | what is reachable on it | every listening socket and published port, on an adopted machine |
 | the firewall it was found with, and the tunnel it carried | on an adopted machine |
 **The architecture and the kernel are already there and nothing reads them.** Measured on the mesh:
 ```
 ace    | amd64 | linux
 g14    | amd64 | linux
 novox  | amd64 | linux
 shanks | amd64 | linux
 ```
 `node show` prints the capabilities and not these two. No code in the control plane reads either.
 ## What is missing
 **The facts.** Nothing is collected about memory, disk, the processor beyond its architecture, the
 distribution and its version, whether the machine is virtual or physical, its uptime, its timezone, how
 many cores it has. Several of those are what somebody actually wants when deciding where a module
 should go, and the comment on module placement already imagines them: *"`seat: card1-DP-1`, an
 architecture, an amount of memory"*.
 **The refresh.** A machine publishes what it knows about itself **after an apply**, and the five-minute
 reconcile publishes nothing. So the mesh's picture of a machine is as old as the last time it sent that
 machine something — found the same day while checking host versions, where three machines read as
 having said nothing until each was pushed
 ([issue 087](../087-the-controller-cannot-tell-a-host-is-too-old/01-resolution.md)). A daily refresh is
 the same missing mechanism: a machine saying something on its own schedule rather than only when spoken
 to.
 **Somewhere to read it.** Whatever is collected has to be visible, or it joins the architecture in
 being true and unread.
 ## The pattern this is the third instance of
 Three times in one day the mesh was found to be collecting something and reading it nowhere:
 - what an adopted machine holds — reported since the adoption work, and no surface counted it until
  [issue 125](../125-a-hold-is-not-a-line-in-the-apply-report/01-resolution.md);
 - the host version — reported for a week, and the control plane's own copy of the report did not have
  the field ([issue 087](../087-the-controller-cannot-tell-a-host-is-too-old/00-report.md));
 - the architecture and kernel — collected, stored, read by nothing, found today by being asked whether
  the host is built for more than one processor
  ([issue 159](../159-an-artifacts-system-is-checked-and-then-ignored/00-report.md)).
 **Collecting is the easy half and it is the half that gets done.** Whatever this issue adds should say,
 in the same breath, which surface shows it — or it will be the fourth.
 ## Why it is not urgent
 Every machine in this mesh is `amd64` and every one reports so. One architecture is enough for now, and
 that is a decision rather than an oversight: a second processor is a second build of every component,
 and nothing needs one.
 ## How a fix is checked
 A machine's own account of itself is visible in one place; it names at least what is listed as missing
 above; the newest of it is no older than a day on a machine nobody has pushed to; and a machine that
 cannot determine one of them says so rather than reporting a zero.