Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Podman ignores labels that are key only #3854

Closed
shaicoleman opened this issue Aug 20, 2019 · 8 comments · Fixed by #5217
Closed

Podman ignores labels that are key only #3854

shaicoleman opened this issue Aug 20, 2019 · 8 comments · Fixed by #5217
Assignees
@kunalkushwaha @mheon
Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@shaicoleman
Copy link

shaicoleman commented Aug 20, 2019 •
edited

/kind bug

Description

Podman 1.5.0 seems to ignore labels that are key only

# Podman version 1.5.0 on Ubuntu (doesn't work)
$ sudo podman run -d -l mylabel --network host docker.io/nginx
$ sudo podman ps --filter=label=mylabel
CONTAINER ID  IMAGE  COMMAND  CREATED  STATUS  PORTS  NAMES

$ sudo podman inspect 33cced6c675b
            "Labels": {
                "maintainer": "NGINX Docker Maintainers <docker-maint@nginx.com>"
            },

Same thing with Docker:

# Docker version 19.03.1 on Ubuntu (works)
sudo docker run -d -l mylabel --network host docker.io/nginx
# sudo docker ps --filter=label=mylabel
CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS              PORTS               NAMES
b8cb18efa8c9        nginx               "nginx -g 'daemon of…"   About a minute ago   Up About a minute                       romantic_brattain

Seems like a regression, because it seems to work with an older version

# Podman version 1.4.4 on CentOS (works)
$ sudo podman run -d -l mylabel --network host docker.io/nginx
$ sudo podman ps --filter=label=mylabel
CONTAINER ID  IMAGE                           COMMAND               CREATED                 STATUS                     PORTS  NAMES
949601197b0b  docker.io/library/nginx:latest  nginx -g daemon o...  Less than a second ago  Up Less than a second ago         musing_blackwell

Output of sudo podman info --debug:

debug:
  compiler: gc
  git commit: ""
  go version: go1.10.4
  podman version: 1.5.0
host:
  BuildahVersion: 1.10.1
  Conmon:
    package: 'conmon: /usr/libexec/podman/conmon'
    path: /usr/libexec/podman/conmon
    version: 'conmon version 2.0.0, commit: unknown'
  Distribution:
    distribution: linuxmint
    version: "19.2"
  MemFree: 5192704000
  MemTotal: 16622612480
  OCIRuntime:
    package: 'containerd.io: /usr/bin/runc'
    path: /usr/bin/runc
    version: |-
      runc version 1.0.0-rc8
      commit: 425e105d5a03fabd737a126ad93d62a9eeede87f
      spec: 1.0.1-dev
  SwapFree: 16984305664
  SwapTotal: 16986927104
  arch: amd64
  cpus: 12
  eventlogger: journald
  hostname: shai-5591
  kernel: 5.0.0-25-generic
  os: linux
  rootless: false
  uptime: 1h 25m 19.89s (Approximately 0.04 days)
registries:
  blocked: null
  insecure: null
  search: null
store:
  ConfigFile: /etc/containers/storage.conf
  ContainerStore:
    number: 64
  GraphDriverName: overlay
  GraphOptions: null
  GraphRoot: /var/lib/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 188
  RunRoot: /var/run/containers/storage
  VolumePath: /var/lib/containers/storage/volumes

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

podman/bionic,now 1.5.0-2~ubuntu18.04~ppa5 amd64 [installed]
@openshift-ci-robot openshift-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Aug 20, 2019
@kunalkushwaha
Copy link
Collaborator

I am able to reproduce this issue, will look into it.

/assign

@kunalkushwaha
Copy link
Collaborator

This issue is already fixed with upstream code.

$ sudo ./bin/podman inspect f122ad694c04 -f {{.Config.Labels}}

map[maintainer:NGINX Docker Maintainers <docker-maint@nginx.com> mylabel:]

Shall be available with next release.

@rhatdan
Copy link
Member

rhatdan commented Aug 26, 2019

Closing.

Should be fixed in podman 1.6

@rhatdan rhatdan closed this as completed Aug 26, 2019
@Jake-Shadle
Copy link

Jake-Shadle commented Feb 14, 2020 •
edited

This seems to have regressed again, at least on 1.8.0, running a container with just a key for the label doesn't add that label.l

podman run -p 9000:9000 -l minio_fetcher --env MINIO_ACCESS_KEY=... --env MINIO_SECRET_KEY=... --env MINIO_DOMAIN=localhost --rm --detach minio/minio:edge server /home/shared

"Labels": {
                "maintainer": "MinIO Inc <dev@min.io>"
            },

debug:
  compiler: gc
  git commit: ""
  go version: go1.13.6
  podman version: 1.8.0
host:
  BuildahVersion: 1.13.1
  CgroupVersion: v2
  Conmon:
    package: conmon-2.0.10-2.fc31.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.10, commit: 6b526d9888abb86b9e7de7dfdeec0da98ad32ee0'
  Distribution:
    distribution: fedora
    version: "31"
  IDMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  MemFree: 48620081152
  MemTotal: 67103920128
  OCIRuntime:
    name: crun
    package: crun-0.12.1-1.fc31.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.12.1
      commit: df5f2b2369b3d9f36d175e1183b26e5cee55dd0a
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  SwapFree: 33676062720
  SwapTotal: 33676062720
  arch: amd64
  cpus: 20
  eventlogger: journald
  hostname: jake-nix
  kernel: 5.4.18-200.fc31.x86_64
  os: linux
  rootless: true
  slirp4netns:
    Executable: /usr/bin/slirp4netns
    Package: slirp4netns-0.4.0-20.1.dev.gitbbd6f25.fc31.x86_64
    Version: |-
      slirp4netns version 0.4.0-beta.3+dev
      commit: bbd6f25c70d5db2a1cd3bfb0416a8db99a75ed7e
  uptime: 6h 38m 40.88s (Approximately 0.25 days)
registries:
  search:
  - docker.io
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - quay.io
store:
  ConfigFile: /home/jake/.config/containers/storage.conf
  ContainerStore:
    number: 105
  GraphDriverName: overlay
  GraphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-0.7.5-2.fc31.x86_64
      Version: |-
        fusermount3 version: 3.6.2
        fuse-overlayfs: version 0.7.5
        FUSE library version 3.6.2
        using FUSE kernel interface version 7.29
  GraphRoot: /home/jake/.local/share/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 63
  RunRoot: /run/user/1000
  VolumePath: /home/jake/.local/share/containers/storage/volumes

@mheon
Copy link
Member

mheon commented Feb 14, 2020

Confirmed, looking into it

@mheon
Copy link
Member

mheon commented Feb 14, 2020

Reopening, given that this is happening again

@mheon mheon reopened this Feb 14, 2020
@mheon mheon self-assigned this Feb 14, 2020
@mheon
Copy link
Member

mheon commented Feb 14, 2020

Looks like our label parsing is rather entangled with environment parsing, which I think is the cause.

mheon added a commit to mheon/libpod that referenced this issue Feb 14, 2020
@mheon
Rework label parsing
71b4022 
We attempted to share all logic for parsing labels and
environment variables, which on the surface makes lots of sense
(both are formatted key=value so parsing logic should be
identical) but has begun to fall apart now that we have added
additional logic to environment variable handling. Environment
variables that are unset, for example, are looked up against
environment variables set for the process. We don't want this for
labels, so we have to split parsing logic.

Fixes containers#3854

Signed-off-by: Matthew Heon <matthew.heon@pm.me>
@mheon mheon mentioned this issue Feb 14, 2020
Merged
mheon added a commit to mheon/libpod that referenced this issue Feb 14, 2020
@mheon
Rework label parsing
fcb435f 
We attempted to share all logic for parsing labels and
environment variables, which on the surface makes lots of sense
(both are formatted key=value so parsing logic should be
identical) but has begun to fall apart now that we have added
additional logic to environment variable handling. Environment
variables that are unset, for example, are looked up against
environment variables set for the process. We don't want this for
labels, so we have to split parsing logic.

Fixes containers#3854

Signed-off-by: Matthew Heon <matthew.heon@pm.me>
mheon added a commit to mheon/libpod that referenced this issue Feb 14, 2020
@mheon
Rework label parsing
c62fc41 
We attempted to share all logic for parsing labels and
environment variables, which on the surface makes lots of sense
(both are formatted key=value so parsing logic should be
identical) but has begun to fall apart now that we have added
additional logic to environment variable handling. Environment
variables that are unset, for example, are looked up against
environment variables set for the process. We don't want this for
labels, so we have to split parsing logic.

Fixes containers#3854

Signed-off-by: Matthew Heon <matthew.heon@pm.me>
mheon added a commit to mheon/libpod that referenced this issue Feb 14, 2020
@mheon
Rework label parsing
36a0ed9 
We attempted to share all logic for parsing labels and
environment variables, which on the surface makes lots of sense
(both are formatted key=value so parsing logic should be
identical) but has begun to fall apart now that we have added
additional logic to environment variable handling. Environment
variables that are unset, for example, are looked up against
environment variables set for the process. We don't want this for
labels, so we have to split parsing logic.

Fixes containers#3854

Signed-off-by: Matthew Heon <matthew.heon@pm.me>
@Jake-Shadle
Copy link

Wow, thanks for the quick response and fix!

snj33v pushed a commit to snj33v/libpod that referenced this issue May 31, 2020
@mheon @snj33v
Rework label parsing
3f8f95a 
We attempted to share all logic for parsing labels and
environment variables, which on the surface makes lots of sense
(both are formatted key=value so parsing logic should be
identical) but has begun to fall apart now that we have added
additional logic to environment variable handling. Environment
variables that are unset, for example, are looked up against
environment variables set for the process. We don't want this for
labels, so we have to split parsing logic.

Fixes containers#3854

Signed-off-by: Matthew Heon <matthew.heon@pm.me>
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 23, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@kunalkushwaha kunalkushwaha

@mheon mheon

Labels
kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Rework label parsing mheon/libpod
6 participants
@shaicoleman @rhatdan @Jake-Shadle @kunalkushwaha @mheon @openshift-ci-robot