Archived
jschoubben
c67f836185
The lab caught this: a module declaring a port and running no container had its rule set opened on 20000 while its service sat on 9101. The firewall reported success and blocked the thing it was told to admit, which is the precise failure the filtering comment warns about, arrived at from the other side. Assignment was applied to every declared port. But a container's mapping is the thing that translates, and where there is none the software binds what it binds — the mesh choosing a number does not move the service, it only makes the mesh wrong about where it is. The declaration side already knew this: publishedOn rewrites container ports and nothing else. Filtering did not, so the two disagreed about the same fact. MachineSide is now the one derivation both follow. It also fixes a second case nobody had hit yet: a mapping the manifest wrote itself, like the mail system's 7080:80. That is passed through untouched when composing, so assigning it a machine port would have opened a rule on a port the container does not publish. Either side of such a mapping now names it, and the host side is the answer — a module may read `listens` as what its software binds or as what the machine exposes, and both readings want the same number. Recorded either way, assigned or not: the map means where this module's port is on this machine, and every reader needs that answer regardless of who chose it. Tests bite — making it always assignable reproduces the lab failure.