You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ADR-0006 files network_mode under rule two; podman honours it, so it belongs to ADR-0003 #115
Found by #109 phase 2, which tried to write a Refusal row for network_mode and could not, because the premise is false.
ADR-0006 opens its list of legitimate rule-two refusals with network_mode, under "where podman cannot [express it], that is a legitimate refusal". Measured on podman 4.9.3, podman expresses it fine, even for a container joining a pod:
pod default : lo 127.0.0.1/8 tap0 10.0.2.100/24
pod + host : lo 127.0.0.1/8 eth0 10.1.0.168/20 docker0 172.17.0.1/16
pod + none : lo 127.0.0.1/8
no pod, host : lo 127.0.0.1/8 eth0 10.1.0.168/20 docker0 172.17.0.1/16
podman run --pod <p> --network host is not ignored and does not error. The container gets the host's interfaces, identical to --network host with no pod at all, and visibly different from the pod's own namespace.
So the refusal is correct but the reason is not. Honouring network_mode is precisely what makes it unacceptable: it pulls the container out of the pod's shared network namespace, which is the thing every other service reaches it on. That is ADR-0003's ruling, and ADR-0003 already names network_mode in exactly that list, alongside links and external_links.
Two consequences:
ADR-0006 should drop network_mode from its rule-two list and point at ADR-0003 instead. Two ADRs currently claim the same key for different reasons, and only one of them is measurable.
network_mode should not get a Refusal row in tests/integration/refusals.py. A row there asserts podman refuses the mount, and podman does not. Phase 3's completeness gate therefore needs to know that an ADR-0003 refusal is out of its scope, or it will demand a row that cannot honestly exist.
Worth noting separately: network_mode is still refused only through the generic unsupported-key path, so a user gets unsupported key 'network_mode' rather than the real reason. Giving it a site of its own with an ADR-0003 message would be an improvement, but it is a separate change from this correction.
Activity