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.
Found by #109 phase 2, which tried to write a
Refusalrow fornetwork_modeand 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:podman run --pod <p> --network hostis not ignored and does not error. The container gets the host's interfaces, identical to--network hostwith 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_modeis 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 namesnetwork_modein exactly that list, alongsidelinksandexternal_links.Two consequences:
network_modefrom 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_modeshould not get aRefusalrow intests/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_modeis still refused only through the generic unsupported-key path, so a user getsunsupported 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.