Closed baszoetekouw closed 6 months ago
Hi @p12tic ! I'm working on the unit tests as you suggested, but I encountered a bit of a problem.
It turns out that docker-compose doesn't support specifying a mac_address
for a specific network interface. Instead, it only allows specification of mac_address
per container, and seems to randomly apply it to one or more of the specified network interfaces (haven't tried this myself as I don't currently have access to a machine running docker, but this seems to be the consensus on stackexchange).
Of course, podman is much nicer than docker and properly supports specification of mac_address
per network (with similar semantics as for ipv4 and ipv6 addresses), so it would be nice if podman-compose could also support this.
There are two choices to make here. First, how to handle the container-level mac_address
option. I see three options:
mac_address
the to all specified networks in the containermac_address
to the first network interface specifiedmac_address
to the first macvlan network interface specifiedI would expect that option 1 might lead to network headaches inside the container, that option 2 is probably most like the original docker-compose behaviour, and option 3 might mostly do what people might expect (as there is usually no reason to specify mac_address
unless you're using a macvlan interface).
And then there's the question if you would like podman-compose to support "extended" podman functionality and allow specification of the mac_addreess
per interface, like this:
services:
some_service:
image: busybox
hostname: myhost
command: ["/bin/busybox", "httpd", "-f", "-h", "/var/www/html", "-p", "8001"]
working_dir: /var/www/html
networks:
shared-network:
ipv4_address: "172.19.1.10"
mac_address: "02:01:01:00:01:01"
internal-network:
ipv4_address: "172.19.2.10"
mac_address: "02:01:01:00:02:01"
Please let me know how you would like me to implement this.
docker-compose spec says it just passes the mac address as --mac-address
option to docker run
. In the docker CLI code there's this logic:
You can see this here https://github.com/docker/cli/blob/a2f3f40233bbe9cd119bed9048973366789de8b5/cli/command/container/opts.go#L810
I think it makes sense to preserve this behavior for the container level mac_address
.
As for network-level mac_address
, we can add this option as podman.mac_address
. If you end up adding it, then please also document it as a podman-compose specific extension in a new file in docs/
.
I've made the changes as you requested:
mac_address
settings are now called podman.mac_address
and this extension is documented in docs/Extensions.mdget_net_args()
now has 100% coveragenetwork_mode
parameter that I encountered while writing the unittestsnetwork_mode
values (private
and pasta
), and documented those (together with the pre-existing podman-specific values slirp4netns
and ns:
) also in docs/Extensions.mdIndeed, I forgot to remove that comment. Fixed now!
Rebased and will merge soon. Thanks!
Currently, podman-compose incorrectly parses docker-compose file with multiple networks, for which the
ipv4_address
,ipv6_address
ormac_address
is specified for each network (see eg #817). There is a partial fix in devel, which solves this issue for the case that the networks addresses are explicitly specified for all defined addresses. However, two cases still fail:mac_address
is specified (either globally or per interface)To be more specific, current HEAD of podman-compose, using this configuration:
fails with:
This is caused by podman-compose parsing the compose file network config to
which in invalid.
With this PR, it executes
so the network arguments are
instead.
Note that I've added a test case for this issue in tests/test_podman_compose_networks.py. I'm not entirely sure this this is the correct way to integrate the tests, so please let me know if I should adjust that.
Closes #817