inspect by kind, not the ambiguous bare form — a same-named network stops a container from ever being found #25
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: novox/mesh-host#25
Reference in New Issue
Block a user
docker inspect <name>resolves across every object kind, not just containers. A module regularly names a network the same as the container that joins it — keycloak does this today, ordinarily, and it works only because keycloak's container already existed the first time this check ever ran against it.Live evidence, novox, tonight: a new module (minio) named its LB container the same as its network ("minio"). Because the container didn't exist yet at first-apply time,
docker inspect minioresolved to the network instead of reporting "no such container" — and the Go template these callers use (.State.Running) fails to execute against a network's JSON (no.Statekey at all), rather than failing to find anything. That reads as "the runtime could not say", which the caller correctly refuses to build on (novox/hq ADR 0100) — but there was something to say; this was a question of kind, not an actual ambiguity that should have stopped anything. Confirmed stuck on novox since first push, retried and failing identically every reconcile.Fix: every call site asking a container's state by name now uses
docker container inspect, matching the type-scoped form this codebase already uses correctly for networks, volumes and images elsewhere (docker network inspect,docker volume inspect,docker image inspect). Five call sites needed it:containerState,inspectFound,NamesFree,raiseGiteaServer,containerRunning. A sixth, already-baredocker inspectinpublish.go(an image lookup) was scoped todocker image inspecttoo, for the same reason, at negligible risk but for consistency.Verified:
go build/go vet/go test ./...all clean — same package list, all passing, as an unmodifiedmain. All seventeen affected test fakes updated to match the new (correct) command shape. Added a new regression test (internal/apply/inspect_scope_test.go) that models Docker's real per-kind namespace behavior and — confirmed by hand — fails if either call site reverts to the bare form.Deployment note:
mesh-hostruns as a host-level service (nox-mesh-host.service), not a Docker-based catalogued module. Merging this does not redeploy it — the live failure on novox persists until the service itself is rebuilt and updated on the node, a separate step from anything this PR does.docker inspect <name> resolves across every object kind, not just containers. A module regularly names a network the same as the container that joins it (keycloak does this today, ordinarily) — so when the container does not exist yet but the same-named network already does, the bare form answers with the network's JSON instead of reporting the container absent, and the template these callers use (.State.Running) fails to execute against it entirely. Live on novox tonight: minio's LB container, named the same as its network ("minio"), could never be created — every apply crashed on "the container runtime could not say whether minio is here", stuck since first push, because the check itself never got a clean answer. Fixed at every call site asking a container's state by name (containerState, inspectFound, NamesFree, raiseGiteaServer, containerRunning) by scoping to `docker container inspect`, matching the type-scoped form this codebase already uses correctly for networks, volumes and images elsewhere. Also scoped the one image inspect that was still bare (publish.go), for the same reason. mesh-host runs as a host-level service (nox-mesh-host.service), not a Docker module — merging this does not redeploy it. The live novox failure persists until the service itself is rebuilt and updated.