You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
As of today podman-compose consults the actual Compose YAML file to get information about ports and assumes that ports are expected to have direct mappings to host, like 8080:80 etc. Otherwise a ValueError: not enough values to unpack (expected 2, got 1) exception is thrown after unpacking.
I presume this was the compromise of providing "at least something", while podman had issues with properly publishing exposed ports and supplying this information via inspect <container> command.
And starting with podman 4.6.x I suspect things can shape up for the better.
Describe the solution you'd like
Latest versions of Podman (>=4.6.0) now correctly supplies all published ports information via podman inspect <container>. This allows podman-compose to take advantage of this, and provide this information as well. A "positive" side-effect of this change - podman-compose becomes more aligned with behavior and output of docker-compose, making switching from Docker to Podman even more appealing to the public (same goes for alias docker-compose=postman-compose).
Another benefit: additional tooling unlocks better support for Podman.
I can definitively say that with proposed change in place testcontainers for python (and mb Java, but I need to check this claim) will start functioning correctly when querying port information. For compose style containers they rely on information from (podman)docker-compose port <container> <port>
Describe alternatives you've considered
The only other alternative is to use podman port command to get this data. This approach does not apply or as easy to implement as soon as you rely on some other tool/abstraction (that has baked-in support for *-compose style commands) instead of direct communication with Docker/Podman clients/sockets: case in point - testcontainers.
Additional context
In case you're looking for analogous output from docker-compose I got you covered
When container is running
$ docker-compose port kong 9090
0.0.0.0:9090
$ docker port kong 9090
0.0.0.0:9090
[::]:9090
When container is not started
$ docker-compose port kong 9090
service "kong" is not running
$ docker port kong 9090
Error response from daemon: No such container: kong
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
As of today
podman-compose
consults the actual Compose YAML file to get information about ports and assumes that ports are expected to have direct mappings to host, like8080:80
etc. Otherwise aValueError: not enough values to unpack (expected 2, got 1)
exception is thrown after unpacking.I presume this was the compromise of providing "at least something", while
podman
had issues with properly publishing exposed ports and supplying this information viainspect <container>
command.And starting with
podman 4.6.x
I suspect things can shape up for the better.Describe the solution you'd like
Latest versions of Podman (>=4.6.0) now correctly supplies all published ports information via
podman inspect <container>
. This allowspodman-compose
to take advantage of this, and provide this information as well. A "positive" side-effect of this change -podman-compose
becomes more aligned with behavior and output ofdocker-compose
, making switching from Docker to Podman even more appealing to the public (same goes foralias docker-compose=postman-compose
).Another benefit: additional tooling unlocks better support for Podman.
I can definitively say that with proposed change in place
testcontainers
forpython
(and mbJava
, but I need to check this claim) will start functioning correctly when querying port information. For compose style containers they rely on information from(podman)docker-compose port <container> <port>
Describe alternatives you've considered
The only other alternative is to use
podman port
command to get this data. This approach does not apply or as easy to implement as soon as you rely on some other tool/abstraction (that has baked-in support for*-compose
style commands) instead of direct communication with Docker/Podman clients/sockets: case in point -testcontainers
.Additional context
In case you're looking for analogous output from
docker-compose
I got you coveredWhen container is running
When container is not started
$ docker-compose port kong 9090 service "kong" is not running $ docker port kong 9090 Error response from daemon: No such container: kong
The text was updated successfully, but these errors were encountered: