Follow-up to #115, split out of #119 rather than guessed at there.
#119 gave network_mode a refusal site of its own, in a _POD_MODEL_REFUSALS table in parsing.py, so it now says why:
service 'app': 'network_mode' is not supported: honouring it would move the container out of
the pod's shared network namespace, where the localhost ports and hostnames its dependents use
stop resolving
ADR-0003 names three more keys in the same clause — "Keys that pull a container out of it (network_mode, links, external_links, expose) are refused permanently" — and all three still fall through to the generic path:
service 'app': unsupported key 'links'
The table is shaped to hold them. What it is not is a reason that fits all four, which is why #119 stopped at one.
The part that needs deciding, not just typing
external_links is close to network_mode's reason: it names a container outside the pod. Probably one sentence away.links is murkier. Docker links inside one shared namespace are not so much escaping as already satisfied — every service is on 127.0.0.1 and in the generated /etc/hosts. A message saying it pulls the container out of the namespace would be false; a message saying it is redundant argues for ignoring it with a warning, not refusing it.expose does not pull anything out of anything. In a shared namespace it is inert, which is the same thing that makes ports an IGNORED_SERVICE_KEYS entry with a warning. If that reading holds, expose is misfiled in ADR-0003 and the fix is a reclassification, not a message.
So this is two questions wearing one coat: which of the three deserve a bespoke message, and whether links/expose are refusals at all or inert keys that ADR-0003 swept up with network_mode because they arrived in the same sentence. The second question needs docker compose config and podman measurements the way #115 needed them — an unmeasured "podman cannot" is exactly what #115 was filed to correct.
Writing one message for all four would restate a reason that later needs correcting, which is the failure mode this repo keeps paying for.
Follow-up to #115, split out of #119 rather than guessed at there.
#119 gave
network_modea refusal site of its own, in a_POD_MODEL_REFUSALStable inparsing.py, so it now says why:ADR-0003 names three more keys in the same clause — "Keys that pull a container out of it (
network_mode,links,external_links,expose) are refused permanently" — and all three still fall through to the generic path:The table is shaped to hold them. What it is not is a reason that fits all four, which is why #119 stopped at one.
The part that needs deciding, not just typing
external_linksis close tonetwork_mode's reason: it names a container outside the pod. Probably one sentence away.linksis murkier. Docker links inside one shared namespace are not so much escaping as already satisfied — every service is on127.0.0.1and in the generated/etc/hosts. A message saying it pulls the container out of the namespace would be false; a message saying it is redundant argues for ignoring it with a warning, not refusing it.exposedoes not pull anything out of anything. In a shared namespace it is inert, which is the same thing that makesportsanIGNORED_SERVICE_KEYSentry with a warning. If that reading holds,exposeis misfiled in ADR-0003 and the fix is a reclassification, not a message.So this is two questions wearing one coat: which of the three deserve a bespoke message, and whether
links/exposeare refusals at all or inert keys that ADR-0003 swept up withnetwork_modebecause they arrived in the same sentence. The second question needsdocker compose configand podman measurements the way #115 needed them — an unmeasured "podman cannot" is exactly what #115 was filed to correct.Writing one message for all four would restate a reason that later needs correcting, which is the failure mode this repo keeps paying for.