Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
containers in pods, connected to other network than "default/podman" are not able to connect to localhost.
Steps to reproduce the issue:
podman network create webpodman pod create --network web --name webpodman container run -dt --name web01 --network web --pod web httpdpodman container run --rm -it --name client01 --pod web --network web alpine wget localhostDescribe the results you received:
The other container not reachable, even if the are in the same pod.
Connecting to localhost ([::1]:80)
wget: can't connect to remote host: Connection refused
Describe the results you expected:
The containers in the same pod are exposed the same way as in the default network. The below example is the same commands as above, but without the specific network.
Connecting to localhost ([::1]:80)
saving to 'index.html'
index.html 100% |**********************************************************************************************************************************************************************************************| 45 0:00:00 ETA
'index.html' saved
Additional information you deem important (e.g. issue happens only occasionally):
Output of podman version:
podman version 2.1.1
Output of podman info --debug:
host:
arch: amd64
buildahVersion: 1.16.1
cgroupManager: systemd
cgroupVersion: v2
conmon:
package: conmon-2.0.21-3.fc33.x86_64
path: /usr/bin/conmon
version: 'conmon version 2.0.21, commit: 0f53fb68333bdead5fe4dc5175703e22cf9882ab'
cpus: 8
distribution:
distribution: fedora
version: "33"
eventLogger: journald
hostname: nb01.while-true-do.io
idMappings:
gidmap: null
uidmap: null
kernel: 5.9.8-200.fc33.x86_64
linkmode: dynamic
memFree: 11252150272
memTotal: 16494235648
ociRuntime:
name: crun
package: crun-0.15.1-1.fc33.x86_64
path: /usr/bin/crun
version: |-
crun version 0.15.1
commit: eb0145e5ad4d8207e84a327248af76663d4e50dd
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
os: linux
remoteSocket:
path: /run/podman/podman.sock
rootless: false
slirp4netns:
executable: ""
package: ""
version: ""
swapFree: 4294963200
swapTotal: 4294963200
uptime: 2h 34m 14.95s (Approximately 0.08 days)
registries:
search:
- registry.fedoraproject.org
- registry.access.redhat.com
- registry.centos.org
- docker.io
store:
configFile: /etc/containers/storage.conf
containerStore:
number: 4
paused: 0
running: 4
stopped: 0
graphDriverName: overlay
graphOptions:
overlay.mountopt: nodev,metacopy=on
graphRoot: /var/lib/containers/storage
graphStatus:
Backing Filesystem: btrfs
Native Overlay Diff: "false"
Supports d_type: "true"
Using metacopy: "true"
imageStore:
number: 4
runRoot: /var/run/containers/storage
volumePath: /var/lib/containers/storage/volumes
version:
APIVersion: 2.0.0
Built: 1602087680
BuiltTime: Wed Oct 7 18:21:20 2020
GitCommit: ""
GoVersion: go1.15.2
OsArch: linux/amd64
Version: 2.1.1
Package info (e.g. output of rpm -q podman or apt list podman):
podman-2.1.1-12.fc33.x86_64
Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?
Yes
Additional environment details (AWS, VirtualBox, physical, etc.):
physical machine
If you specify --network on the run command you overwrite the pod net namespace.
You should use podman container run -dt --name web01 --pod web httpd
Thanks a lot. This is working perfectly fine.
I would suggest to make this idiot proof as a feature request, if this is ok for you :+1:
/close
@zhangguanzhang: Closing this issue.
In response to this:
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
I disagree with closing it, as Daniel wrote, it should be clearer, at least in the man pages, that setting the network overwrites the pod's namespace.
I would suggest to make this idiot proof as a feature request, if this is ok for you
Well the problem is that this a legitimate use case. I don't know how we can separate between someone who wants this and someone who did this by accident.
Maybe need to throw an error directly when creating it to prevent the pod from being created?
if this is a legitimate use case to have networks attached to pods and containers in this pod, than I am ok with closing it. Otherwise a documentation hint for podman-create --network would be ok for me.
I opened #8367 to improve the docs.
Most helpful comment
I opened #8367 to improve the docs.