Split out of #120, which refused links as a tracked limitation rather than guessing at an implementation in the same PR.
links is refused today, with a message naming the two keys that replace it by hand:
service 'app': 'links' is not supported: docker reads it as a dependency on the linked
service plus a hostname alias (measured, v5.1.2), and compose2pod takes neither from this
key -- declare the dependency in 'depends_on' and the alias in 'networks.<network>.aliases'
Why this is implementable rather than permanent
docker compose config v5.1.2 normalizes the key into two things compose2pod already has machinery for:
# in
app: {links: ["db:database"]}
# out
app:
depends_on:
db: {condition: service_started, restart: true, required: true}
links: ["db:database"]
- The edge is a
depends_on with condition: service_started, which is graph.depends_on / graph.startup_order's existing default condition.
- The alias is a name the service is reachable by, which is what
graph._host_names already collects from hostname, container_name and networks.<net>.aliases, and pod.hosts_file_tokens already renders at 127.0.0.1.
So the work is wiring, not new capability.
What needs care
- The plain form.
links: [db] carries the edge and no alias, since db already resolves. It must still create the dependency.
- Ghost targets. Docker rejects
links: [ghost] with service "app" depends on undefined service "ghost". Whatever reads the key has to refuse that, and it interacts with #87: a links entry outside the target's closure would land in the same residual, so it should be added to tests/conformance/corpus_residual/ rather than quietly accepted.
- Alias collisions.
pod.hosts_file_tokens refuses a name that lands on two addresses. A links alias colliding with an extra_hosts entry must refuse the same way, and get a test.
restart: true appears in docker's normalized output. Worth measuring whether it means anything for a pod the script tears down with pod rm -f, before either honouring or ignoring it.
Done when
tests/conformance/corpus/service_links_alias.yaml flips from over-reject to both-accept, and test_service_links_is_a_catalogued_over_rejection is deleted with it -- the assertion is written to fail the day the limitation closes, so it will say when this is finished.
Split out of #120, which refused
linksas a tracked limitation rather than guessing at an implementation in the same PR.linksis refused today, with a message naming the two keys that replace it by hand:Why this is implementable rather than permanent
docker compose configv5.1.2 normalizes the key into two things compose2pod already has machinery for:depends_onwithcondition: service_started, which isgraph.depends_on/graph.startup_order's existing default condition.graph._host_namesalready collects fromhostname,container_nameandnetworks.<net>.aliases, andpod.hosts_file_tokensalready renders at127.0.0.1.So the work is wiring, not new capability.
What needs care
links: [db]carries the edge and no alias, sincedbalready resolves. It must still create the dependency.links: [ghost]withservice "app" depends on undefined service "ghost". Whatever reads the key has to refuse that, and it interacts with #87: alinksentry outside the target's closure would land in the same residual, so it should be added totests/conformance/corpus_residual/rather than quietly accepted.pod.hosts_file_tokensrefuses a name that lands on two addresses. Alinksalias colliding with anextra_hostsentry must refuse the same way, and get a test.restart: trueappears in docker's normalized output. Worth measuring whether it means anything for a pod the script tears down withpod rm -f, before either honouring or ignoring it.Done when
tests/conformance/corpus/service_links_alias.yamlflips fromover-rejecttoboth-accept, andtest_service_links_is_a_catalogued_over_rejectionis deleted with it -- the assertion is written to fail the day the limitation closes, so it will say when this is finished.