podman ps: output unreadable with many exposed ports #23317
Comments
|
Yeah it doesn't look very nice, to be honest I still don't understand why this is shown at all in docker... Adding a new cli options seems awkward (would you actual remember to type this?). Having to use a special option every time is not great. One other option is to trim off ports when the result string length is greater than 20 (or some other number?). This is already done for the command field. But that would not be fully compatible with docker. I noticed one other problem though we do not merge ranges for exposed ports, docker does. That is certainly something that has to be fixed. |
Yes. An option in containers.conf to default to the Podman ps output prior to 5.1 would be an excellent idea. Regarding macvlan. It's just where I noticed the change the most, seeing how the output went from nothing to a wall of text.
This would clean things up substantially. I don't use Docker, so I didn't realize it grouped ports into ranges. |
Well given you example this would not help much only |
skyblaster
changed the title
True, that wasn't the best example. The FreeSWITCH example I referenced first was much better. It's just that I couldn't link to a public image for demo purposes. This is just a small sample of the wall of text I was referring to:
I did attempt a fix, which does work, however I'm sure the code quality is not up to par for this project: This brings up another area that could benefit from grouping. Which is very different from the non-grouped output of |
|
I believe the podman inspect output must be that way for docker compat, they do not group port ranges there AFAIK. |
|
A friendly reminder that this issue had no activity for 30 days. |
|
Hello,
We are using multiple containers which have to expose lots of ports and now the output is really not readable. It's even the case for the containers that don't expose ports because it creates spaces corresponding to the size of the largest "PORTS" String. You can see an example on the following screenshot (I had to hide the data corresponding to our containers, sorry) : |
|
🙌 same 💩 here |
|
Hello @Luap99 , Any plan to correct this issue ? |
|
PRs welcome, otherwise I get to it when I get to it. And yes of course I would love to fix this but time is limited. |
This fixes two problems, first if a port is published and exposed it should not be shown twice. It is enough to show the published one. Second, if there is a huge range the ports were no grouped causing the output to be unreadable basically. Now we group exposed ports like we do with the normal published ports. Fixes containers#23317 Signed-off-by: Paul Holzinger <[email protected]>
This fixes two problems, first if a port is published and exposed it should not be shown twice. It is enough to show the published one. Second, if there is a huge range the ports were no grouped causing the output to be unreadable basically. Now we group exposed ports like we do with the normal published ports. Fixes containers#23317 Signed-off-by: Paul Holzinger <[email protected]>
|
Fix in #24337 |
Issue Description
After a recent upgrade from 5.0.3 to 5.1.0, I noticed that podman ps is unreadable.
This is due to my FreeSWITCH container, which uses a macvlan network and has many exposed ports (see here).
Prior to 5.1, this and other containers using macvlan networks would not list any ports at all.
This appears to be intended behaviour introduced by PR #22319
Is it possible to add a flag to mute port information for macvlan containers?
Steps to reproduce the issue
Steps to reproduce the issue...using adguardhome as an example:
Describe the results you received
Describe the results you expected
podman info output
Podman in a container
No
Privileged Or Rootless
Privileged
Upstream Latest Release
No
Additional environment details
Additional environment details
Additional information
Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting
The text was updated successfully, but these errors were encountered: