The events API is not Docker-compatible when using the same filter multiple times

[ahmed-mez]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

Podman's events API doesn't handle the case where the same filter is used multiple times like Docker does.

Docker documentation: https://docs.docker.com/engine/reference/commandline/events/

Using the same filter multiple times will be handled as a OR; for example --filter container=588a23dac085 --filter container=a8f7720b8c22 will display events for container 588a23dac085 OR container a8f7720b8c22

However, Podman will still apply an AND instead of an OR for the example above.

Steps to reproduce the issue:

1. Run two containers

podman run -d nginx
80fe6eb5f585dde552491f3b0c77751a19045e99211c0d72c539833859f9b5d3

podman run -d redis
1c62ec17cb44e183f83db5261551bd0d5c0db75e0973e8bbf32c97e41b5700a1

podman ps
CONTAINER ID  IMAGE                           COMMAND               CREATED         STATUS             PORTS   NAMES
80fe6eb5f585  docker.io/library/nginx:latest  nginx -g daemon o...  13 seconds ago  Up 13 seconds ago          cranky_banzai
1c62ec17cb44  docker.io/library/redis:latest  redis-server          5 seconds ago   Up 5 seconds ago           gracious_khorana

2. Query events for both containers (doesn't work)

podman events --since 5m --filter "container=80fe6eb5f585" --filter "container=1c62ec17cb44"
# No events shown!

3. Query events for one container (works)

podman events --since 5m --filter "container=1c62ec17cb44"
2021-05-31 09:36:09.923083952 +0000 UTC container create 1c62ec17cb44e183f83db5261551bd0d5c0db75e0973e8bbf32c97e41b5700a1 (image=docker.io/library/redis:latest, name=gracious_khorana)
2021-05-31 09:36:10.200379849 +0000 UTC container init 1c62ec17cb44e183f83db5261551bd0d5c0db75e0973e8bbf32c97e41b5700a1 (image=docker.io/library/redis:latest, name=gracious_khorana)
2021-05-31 09:36:10.212573077 +0000 UTC container start 1c62ec17cb44e183f83db5261551bd0d5c0db75e0973e8bbf32c97e41b5700a1 (image=docker.io/library/redis:latest, name=gracious_khorana)

Describe the results you received:

Using the container filter more than once hasn't been considered as an OR.

Describe the results you expected:

Same behaviour as Docker: Using the same filter multiple times will be handled as a OR.

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

Output of podman version:

podman version
Version:      3.1.2
API Version:  3.1.2
Go Version:   go1.14.12
Built:        Fri Apr 23 13:43:22 2021
OS/Arch:      linux/amd64

Output of podman info --debug:

podman info --debug
host:
  arch: amd64
  buildahVersion: 1.20.1
  cgroupManager: systemd
  cgroupVersion: v1
  conmon:
    package: conmon-2.0.28-1.el8.2.1.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.28, commit: '
  cpus: 2
  distribution:
    distribution: '"centos"'
    version: "8"
  eventLogger: journald
  hostname: centos8
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 4.18.0-240.1.1.el8_3.x86_64
  linkmode: dynamic
  memFree: 375107584
  memTotal: 2073030656
  ociRuntime:
    name: crun
    package: crun-0.19.1-1.el8.2.1.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.19.1
      commit: 1535fedf0b83fb898d449f9680000f729ba719f5
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: false
    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
    selinuxEnabled: true
  slirp4netns:
    executable: ""
    package: ""
    version: ""
  swapFree: 2145382400
  swapTotal: 2147479552
  uptime: 1h 22m 32.59s (Approximately 0.04 days)
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - docker.io
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 2
    paused: 0
    running: 2
    stopped: 0
  graphDriverName: overlay
  graphOptions:
    overlay.mountopt: nodev
  graphRoot: /var/lib/containers/storage
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 5
  runRoot: /run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 3.1.2
  Built: 1619185402
  BuiltTime: Fri Apr 23 13:43:22 2021
  GitCommit: ""
  GoVersion: go1.14.12
  OsArch: linux/amd64
  Version: 3.1.2

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

rpm -q podman
podman-3.1.2-1.el8.2.1.x86_64

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

Yes

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

VirtualBox

[vrothberg]

Thanks for opening the issue!

We need to fix it in libpod/events. Currently, we transform the filters into a []EventFilter. To support the disjunctive filtering for the same filter, we should transform the slice into map[string][]EventFilter with the map key being the filter key (remaining conjunctive) with the value ([]EventFilter) being disjunctive. In other words, at least one filter for a given key must return true.

[ahmed-mez]

Thank you @vrothberg for the detailed response! I'd be happy to contribute a fix in the coming weeks.

[vrothberg]

Thanks, @ahmed-mez! I will try to tackle it today. We are close to a release, and it would be good to have a fix for it in.

[ahmed-mez]

Sounds great, thank you!

[vrothberg]

I opened #10514 to fix the issue.

[ahmed-mez]

hey @vrothberg , thank you for fixing this! I thought v3.2 was released (based on Github releases) but, as of today, it does not exist on Kubic. Should we expect it to be released this week?
I tried the 3.2.0-1.rc3 available on the testing repo but it didn't include this fix apparently.

[vrothberg]

Thanks for reaching out. It should land in Kubic soon (Cc @lsm5).

-rc3 did not include the fix yet.