mac-proxy: misnamed (agents run it off-Mac too) + orphaned compose.override.yaml found on the Windows tower #550

New issue

Open

opened 2026-07-12 21:27:22 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-07-12 21:27:22 +00:00

Member

Found untracked in the Windows tower checkout at ansible/roles/mac-proxy/files/compose.override.yaml (2026-07-12), preserved here before deletion from disk. Full contents:

networks:
  ward-tailnet:
    external: true

Context:

The override flips ward-tailnet from created-by-compose (compose.yaml pins name: ward-tailnet) to external: true - the standard workaround when docker compose up refuses to reuse an already-existing network. Someone was debugging that conflict and parked the override next to the tracked compose file.
It is inert through ansible: tasks/main.yml copies and runs compose.yaml only, so the override never reaches a host via the role. It only matters when compose runs by hand from the role's files dir.
It surfaced on the WINDOWS tower, not a Mac - which supports Kai's read that the role name is wrong: the proxy is not Mac-specific, agents apparently need to run it from other hosts sometimes too. Consider renaming the role/service (ward-proxy? tailnet-proxy?) and, if the network-exists conflict is a real recurring failure, wiring the external-network handling into the tracked compose.yaml instead of a loose override.

Found untracked in the Windows tower checkout at ansible/roles/mac-proxy/files/compose.override.yaml (2026-07-12), preserved here before deletion from disk. Full contents: ```yaml networks: ward-tailnet: external: true ``` Context: * The override flips ward-tailnet from created-by-compose (compose.yaml pins name: ward-tailnet) to external: true - the standard workaround when docker compose up refuses to reuse an already-existing network. Someone was debugging that conflict and parked the override next to the tracked compose file. * It is inert through ansible: tasks/main.yml copies and runs compose.yaml only, so the override never reaches a host via the role. It only matters when compose runs by hand from the role's files dir. * It surfaced on the WINDOWS tower, not a Mac - which supports Kai's read that the role name is wrong: the proxy is not Mac-specific, agents apparently need to run it from other hosts sometimes too. Consider renaming the role/service (ward-proxy? tailnet-proxy?) and, if the network-exists conflict is a real recurring failure, wiring the external-network handling into the tracked compose.yaml instead of a loose override.