1.6 KiB
status, opened, located-in, fixed-by
| status | opened | located-in | fixed-by | |
|---|---|---|---|---|
| resolved | 2026-09-22 |
|
mesh-controller multiple-fixes (the facts take a name as the control plane keys it, internal or bare, and write each machine once); a unit test holds both keyings to the same files |
079 — Every machine is named twice over in the hosts file and the resolver's zones
Symptom
The hosts file the mesh writes on every machine, and the zones file it hands a resolver, name each
machine as <machine>.internal.internal, with the intended name <machine>.internal in the
hosts file's second column. Names still resolve on the machine itself, because the second column
matches, so nothing noticed. A resolver serving the zones answers for *.<machine>.internal.internal
and for nothing under <machine>.internal, so a service named under a machine does not resolve
from anywhere.
Found by running the large mesh bed end to end for the first time since the mesh's knowledge became a fact a module asks for: its name test read the zones back. No smaller bed reads them.
Why it matters beyond the instance
Two functions agreed on a contract nobody wrote down: the caller keyed the map by the internal name, the facts appended the suffix to a bare one. Each was tested alone, with its own keying, and both passed. A file the mesh writes and nothing reads back in a test is a file that can be wrong for as long as it takes someone to look.
What would close it
The facts take either keying and write each machine once, held by a test that feeds both. And a bed reads the files back — the large mesh bed does now.