podman "died" event lacking container labels

[thediveo]

/kind bug

Description

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.1 LTS
Release:        22.04
Codename:       jammy

Please note: this is the newest version of podman available on Ubuntu 22.04.1 LTS. I also tried using the Debian experimental package http://ftp.us.debian.org/debian/pool/main/libp/libpod/podman_4.2.0+ds1-3_amd64.deb with the same result.

Steps to reproduce the issue:

1. sudo podman events

2. run a separate sudo podman run -it --rm --name test --label foo=bar busybox echo hi

Describe the results you received:

2022-09-02 18:09:41.538575194 +0200 CEST container history f4afca196a33111c1c956e5283deed1e092d2bbde96e59b6e94eb0d0113d67d1 (image=, name=)
2022-09-02 18:09:41.541461167 +0200 CEST container create f4afca196a33111c1c956e5283deed1e092d2bbde96e59b6e94eb0d0113d67d1 (image=docker.io/library/busybox:latest, name=test, foo=bar)
2022-09-02 18:09:41.520258047 +0200 CEST image pull  busybox
2022-09-02 18:09:41.741552231 +0200 CEST container init f4afca196a33111c1c956e5283deed1e092d2bbde96e59b6e94eb0d0113d67d1 (image=docker.io/library/busybox:latest, name=test, foo=bar)
2022-09-02 18:09:41.746178967 +0200 CEST container start f4afca196a33111c1c956e5283deed1e092d2bbde96e59b6e94eb0d0113d67d1 (image=docker.io/library/busybox:latest, name=test, foo=bar)
2022-09-02 18:09:41.746306934 +0200 CEST container attach f4afca196a33111c1c956e5283deed1e092d2bbde96e59b6e94eb0d0113d67d1 (image=docker.io/library/busybox:latest, name=test, foo=bar)
2022-09-02 18:09:41.747355852 +0200 CEST container died f4afca196a33111c1c956e5283deed1e092d2bbde96e59b6e94eb0d0113d67d1 (image=docker.io/library/busybox:latest, name=test)
2022-09-02 18:09:41.927988109 +0200 CEST container remove f4afca196a33111c1c956e5283deed1e092d2bbde96e59b6e94eb0d0113d67d1 (image=docker.io/library/busybox:latest, name=test, foo=bar)

Describe the results you expected:

...the "container died" event to contain the died container's foo=bar label.

Additional information you deem important (e.g. issue happens only occasionally):

For reference, the same event when using Docker, notice the foo=bar label being present:

2022-09-02T18:11:25.919385791+02:00 container die 608a0745d32b8aae900200037ba110c579bd392c86aa90ac66c82927fcc1c796 (exitCode=0, foo=bar, image=busybox, name=test)

Output of podman version:

This affects v4.2.0 as well.

Version:      3.4.4
API Version:  3.4.4
Go Version:   go1.17.3
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

Output of podman info:

host:
  arch: amd64
  buildahVersion: 1.23.1
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - hugetlb
  - pids
  - rdma
  - misc
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: 'conmon: /usr/bin/conmon'
    path: /usr/bin/conmon
    version: 'conmon version 2.0.25, commit: unknown'
  cpus: 8
  distribution:
    codename: jammy
    distribution: ubuntu
    version: "22.04"
  eventLogger: journald
  hostname: **redacted**
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.15.0-47-generic
  linkmode: dynamic
  logDriver: journald
  memFree: 3693629440
  memTotal: 16642666496
  ociRuntime:
    name: crun
    package: 'crun: /usr/bin/crun'
    path: /usr/bin/crun
    version: |-
      crun version 0.17
      commit: 0e9229ae34caaebcb86f1fde18de3acaf18c6d9a
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    exists: true
    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: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: 'slirp4netns: /usr/bin/slirp4netns'
    version: |-
      slirp4netns version 1.0.1
      commit: 6a7b16babc95b6a3056b33fb45b74a6f62262dd4
      libslirp: 4.6.1
  swapFree: 2147479552
  swapTotal: 2147479552
  uptime: 46h 36m 34.32s (Approximately 1.92 days)
plugins:
  log:
  - k8s-file
  - none
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries: {}
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /var/lib/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 1
  runRoot: /run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 3.4.4
  Built: 0
  BuiltTime: Thu Jan  1 01:00:00 1970
  GitCommit: ""
  GoVersion: go1.17.3
  OsArch: linux/amd64
  Version: 3.4.4

Package info (e.g. output of rpm -q podman or apt list podman):

podman/jammy,now 3.4.4+ds1-1ubuntu1 amd64 [installed]

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)

Yes

This is the latest version available on Ubuntu 22.04.1 LTS. I also tried using the Debian experimental package http://ftp.us.debian.org/debian/pool/main/libp/libpod/podman_4.2.0+ds1-3_amd64.deb with the same result.

Additional environment details (AWS, VirtualBox, physical, etc.):

none.

[thediveo]

This bug affects at least v3 and v4 of podman. It triggers my unit tests to fail due to the incompatibility.

[vrothberg]

Thanks for reaching out, @thediveo!

I can reproduce on Podman v4.2.

[thediveo]

Oh well, earned a "nudge label" 😁...

1. would

   podman/libpod/events.go

   Line 51 in 098c071

   func (c *Container) newContainerExitedEvent(exitCode int32) {

   be the correct place to mess with the code base in order to add labels?
2. and while I'm at this, do you want me to also add labels to other events in case they lack them when compared to the Docker events?
3. what about pods: here, we don't have any Docker feature parity to achieve. Would you like the "Adrian Monk" approach to achieve symmetry by adding pod labels to the pod-related events, too?

[vrothberg]

1. yes that looks like the right place to me.
2. yes that would awesome, thanks a ton!
3. looks like a separate issue. Probably worth opening a separate issue/RFE for it?

Thanks for sharing ideas and for contributing!

[thediveo]

@vrothberg events.Event has both the Attributes and Details.Attributes fields. newContainerEvent passes the container labels as Details.Attributes. Shall I do the same for newContainerExitedEvent and newExecDiedEvent?

[thediveo]

PR #15633