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.

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

podman play kube does not pull images like it should #4880

Closed
ghost opened this issue Jan 16, 2020 · 6 comments · Fixed by #4993
Closed

podman play kube does not pull images like it should #4880

ghost opened this issue Jan 16, 2020 · 6 comments · Fixed by #4993
Assignees
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

@ghost
Copy link

ghost commented Jan 16, 2020

/kind bug

podman play kube does not seem to be pulling updated images as directed by the :latest tag or imagePullPolicy: always.

Steps to reproduce the issue:

  1. podman stop/remove an outdated container
  2. podman play kube a .yml containing the :latest tag or imagePullPolicy: always
  3. The container is recreated from the outdated image

Output of podman version:

Version:            1.7.0
RemoteAPI Version:  1
Go Version:         go1.13.5
OS/Arch:            linux/amd64

Output of podman info --debug:

debug:
  compiler: gc
  git commit: ""
  go version: go1.13.5
  podman version: 1.7.0
host:
  BuildahVersion: 1.12.0
  CgroupVersion: v2
  Conmon:
    package: conmon-2.0.2-1.fc31.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.2, commit: 186a550ba0866ce799d74006dab97969a2107979'
  Distribution:
    distribution: fedora
    version: "31"
  OCIRuntime:
    name: crun
    package: crun-0.10.6-1.fc31.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.10.6
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  arch: amd64
  cpus: 12
  eventlogger: journald
  kernel: 5.3.16-300.fc31.x86_64
  os: linux
  rootless: false
registries:
  search:
  - docker.io
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - registry.centos.org
  - quay.io
store:
  ConfigFile: /etc/containers/storage.conf
  ContainerStore:
    number: 26
  GraphDriverName: overlay
  GraphOptions:
    overlay.mountopt: nodev,metacopy=on
  GraphRoot: /var/lib/containers/storage
  GraphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "true"
  ImageStore:
    number: 12
  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-1.7.0-2.fc31.x86_64
@openshift-ci-robot openshift-ci-robot added the kind/bug Categorizes issue or PR as related to a bug. label Jan 16, 2020
@rhatdan
Copy link
Member

rhatdan commented Jan 16, 2020

@komic Do you have a simple kubernernetes.yaml file we could test with?

@ghost
Copy link
Author

ghost commented Jan 16, 2020

A basic example:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2020-01-15T22:26:19Z"
  labels:
    app: plex
  name: pod-plex
spec:
  containers:
    image: docker.io/linuxserver/plex:latest
    imagePullPolicy: always
    name: plex
    resources: {}
    securityContext:
      allowPrivilegeEscalation: true
      capabilities: {}
      privileged: false
      readOnlyRootFilesystem: false
    workingDir: /
status: {}

@baude
Copy link
Member

baude commented Jan 26, 2020

@komic I can understand that imagePullPolicy: always would trigger a pull of the latest but at least in podman, there is no precedent for triggering a pull based on the latest tag. Would honoring the pull policy be sufficient?

@baude baude self-assigned this Jan 26, 2020
baude added a commit to baude/podman that referenced this issue Jan 27, 2020
When a container specification has a pull policy, we should honor it when recreating the pods/containers from yaml.

Fixes: containers#4880

Signed-off-by: Brent Baude <bbaude@redhat.com>
@ghost
Copy link
Author

ghost commented Jan 27, 2020

Of course, that does not match the behavior described by https://kubernetes.io/docs/concepts/containers/images/ though.

baude added a commit to baude/podman that referenced this issue Jan 28, 2020
When a container specification has a pull policy, we should honor it when recreating the pods/containers from yaml.  furthermore, ini kube, if a tag is :latest, then the always pull policy is automatically instituted.

Fixes: containers#4880

Signed-off-by: Brent Baude <bbaude@redhat.com>
baude added a commit to baude/podman that referenced this issue Jan 28, 2020
When a container specification has a pull policy, we should honor it when recreating the pods/containers from yaml.  furthermore, ini kube, if a tag is :latest, then the always pull policy is automatically instituted.

Fixes: containers#4880

Signed-off-by: Brent Baude <bbaude@redhat.com>
@baude
Copy link
Member

baude commented Jan 28, 2020

@komic both pieces were added to play kube!

@ghost
Copy link
Author

ghost commented Jan 29, 2020

Good stuff, thank you all!

@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.
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
Development

Successfully merging a pull request may close this issue.

4 participants