Closed moschroe closed 1 year ago
@Luap99 PTAL
The difference is that Podman is not creating a network namespace, but the OCI runtime. With other network modes, we create and manage the namespace ourselves to ensure it can be set up as required. For --net=none
no setup is required so we delegate to the OCI runtime. As such, we don't know the path to the namespace, though I suppose we could shove /proc/$containerpid/ns/net
in the output of inspect.
I think adding /proc/$containerpid/ns/net
makes sense. I would prefer that over actually bind mounting the netns since this is more expensive and we would need to manually clean it up.
@moschroe Would /proc/$containerpid/ns/net
work for you?
A friendly reminder that this issue had no activity for 30 days.
@moschroe Friendly ping
This issue is blocking this other feature: https://github.com/GNS3/gns3-server/issues/1811
@Luap99 can you just do your suggestion and we can move on.
@moschroe Friendly ping
Sorry, lost track of this issue. I built a workaround for one tool using the manually determined path in /proc
but propagating that in the API response should certainly fix it for everything else as well. I wholeheartedly approve!
A friendly reminder that this issue had no activity for 30 days.
@Luap99 any time to work on this one?
PR #19444
BUG REPORT
/kind bug
Description
podman inspect $container
does not yield.NetworkConfig.SandboxKey
when a container was started with--network=none
. I believe this to be a bug because a network namespace is created (there are no interfaces apart fromlo
present inside the container) and using the PID at.State.Pid
, the namespace can be named and entered withip netns attach $name $PID
andip netns exec $name $command
.The combination of setting up containers without network interfaces and then accessing their network namespace is needed to inject externally configured network interfaces (like wireguard) into an otherwise isolated container. While this is possible by using the PID, it would require reworking of existing tooling already compatible with docker.
Steps to reproduce the issue:
podman run --rm -i --name test-container --network=none docker.io/library/alpine:3.17
Describe the results you received:
The command
podman inspect test-container | jq ".[0].NetworkSettings | [.SandboxID, .SandboxKey]"
yields empty strings instead of the expected .SandboxKey (and optional .SandboxID).Root/non-root does not make a difference, neither does changing the network backend to netavark.
Describe the results you expected:
The network namespace should have been established in the filesystem and made accessible through the
.NetworkConfig.SandboxKey
key. Here a working example for--network=default
(or anything other than "none"):The equivalent
docker run --rm -i --name test-container --network=none docker.io/library/alpine:3.17
followed bydocker inspect test-container | jq ".[0].NetworkSettings | [.SandboxID, .SandboxKey]"
will accurately report the SandboxKey.Additional information you deem important (e.g. issue happens only occasionally):
Output of
podman version
:Output of
podman info
:Package info (e.g. output of
rpm -q podman
orapt list podman
orbrew info podman
):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.):
N/A