Breaking behavior change with inspected hostIP for port forward

BenTheElder commented 3 days ago

Issue Description

This was brought up in https://github.com/containers/podman/issues/17780, but a key detail was missing: this isn't just an incompatibile change versus docker, this is an incompatible change versus prior podman releases.

For now we have a workaround in kind to assume loopback works from the host, but we'd really prefer to get accurate information from the runtime actually implementing the port forward and to avoid breaking behavior changes if possible.

Thanks in advance.

Steps to reproduce the issue

Create a container with a port forward with the default address, inspect the container and find that hostIP is empty despite the port forward clearly being bound to something. No usable IP is reported.

Describe the results you received

Empty hostIP field

Describe the results you expected

A valid usable hostIP, like previous podman releases.

podman info output

host:
  arch: amd64
  buildahVersion: 1.33.7
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - hugetlb
  - pids
  - rdma
  - misc
  cgroupManager: cgroupfs
  cgroupVersion: v2
  conmon:
    package: Unknown
    path: /usr/local/lib/podman/conmon
    version: 'conmon version 2.1.10, commit: 2dcd736e46ded79a53339462bc251694b150f870'
  cpuUtilization:
    idlePercent: 95.69
    systemPercent: 1.18
    userPercent: 3.13
  cpus: 224
  databaseBackend: sqlite
  distribution:
    codename: jammy
    distribution: ubuntu
    version: "22.04"
  eventLogger: file
  freeLocks: 2046
  hostname: cuke-metax-demo-001
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.15.0-112-generic
  linkmode: dynamic
  logDriver: k8s-file
  memFree: 2075498274816
  memTotal: 2164076400640
  networkBackend: cni
  networkBackendInfo:
    backend: cni
    dns: {}
  ociRuntime:
    name: /opt/dce5/bin/runc
    package: Unknown
    path: /opt/dce5/bin/runc
    version: |-
      runc version 1.1.12
      commit: v1.1.12-0-g51d5e946
      spec: 1.0.2-dev
      go: go1.20.13
      libseccomp: 2.5.4
  os: linux
  pasta:
    executable: ""
    package: ""
    version: ""
  remoteSocket:
    exists: false
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: true
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: ""
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/local/bin/slirp4netns
    package: Unknown
    version: |-
      slirp4netns version 1.2.3
      commit: c22fde291bb35b354e6ca44d13be181c76a0a432
      libslirp: 4.7.0
      SLIRP_CONFIG_VERSION_MAX: 4
      libseccomp: 2.5.4
  swapFree: 0
  swapTotal: 0
  uptime: 16h 25m 47.00s (Approximately 0.67 days)
  variant: ""
plugins:
  authorization: null
  log:
  - k8s-file
  - none
  - passthrough
  network:
  - bridge
  - macvlan
  - ipvlan
  volume:
  - local
registries:
  search:
  - docker.io
  - registry.fedoraproject.org
  - registry.access.redhat.com
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 1
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.ignore_chown_errors: "true"
    overlay.mount_program:
      Executable: /usr/local/bin/fuse-overlayfs
      Package: Unknown
      Version: |-
        fuse-overlayfs: version 1.13-dev
        fusermount3 version: 3.10.5
        FUSE library version 3.16.2
        using FUSE kernel interface version 7.38
    overlay.mountopt: nodev,fsync=0
  graphRoot: /var/lib/containers/storage
  graphRootAllocated: 475519213568
  graphRootUsed: 158235852800
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Supports shifting: "true"
    Supports volatile: "true"
    Using metacopy: "false"
  imageCopyTmpDir: /var/tmp
  imageStore:
    number: 1
  runRoot: /var/run/containers/storage
  transientStore: false
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 4.9.4
  Built: 0
  BuiltTime: Thu Jan  1 00:00:00 1970
  GitCommit: ""
  GoVersion: go1.20.14
  Os: linux
  OsArch: linux/amd64
  Version: 4.9.4

(From https://github.com/kubernetes-sigs/kind/issues/3777)

Podman in a container

No

Privileged Or Rootless

Privileged

Upstream Latest Release

Yes

Additional environment details

No response

Additional information

Originally discovered in https://github.com/kubernetes-sigs/kind/issues/3777

Luap99 commented 2 days ago

You are using podman 4.9.4 and as mentioned in the closed linked issue it was fixed in 5.0. Why are you creating a new issue about this, did you actually test this with the latest podman?

BenTheElder commented 2 days ago

I am not the podman user but I am attempting to close the loop between the projects as a maintainer of https://github.com/kubernetes-sigs/kind, the original user only reported it to us.

Thank you for fixing this.

containers / podman