search

containers / podman-compose

a script to run docker-compose.yml using podman
GNU General Public License v2.0
5.01k stars 477 forks source link

podman-compose up -d --pull-always does not always pull #850

Open kewiha opened 7 months ago

kewiha commented 7 months ago

Describe the bug podman-compose up --help lists --pull-always as an argument that should pull the latest image every time.

This argument does not add --pull always or equivalent to the podman run command executed by podman-compose. Old local images are used instead of the behaviour described by podman-compose up --help. This affects all my containers and compose files.

As an aside, adding pull_policy: always in the docker-compose.yaml file works properly. It adds --pull always to the podman run command, and old local images are not used.

I'm running podman-compose 1.0.6 from debian bookworm backports, podman version 4.3.1 from debian bookworm. I installed the latest devel version (as of about an hour ago) and get the same behaviour.

To Reproduce Steps to reproduce the behavior:

  1. Run podman-compose up -d --pull-always, preferably with a container whose image is updated frequently. Use the "latest" tag or omit the tag.
  2. Allow some time to pass until your local version of "latest" is out of date. There may be a shortcut for this that I'm not aware of (e.g. download an old version, change the tag to latest).
  3. Run podman-compose down and then podman-compose up -d --pull-always. The latest "latest" should have been pulled, but it is not. This is the bug.
  4. Optional: add pull_policy: always and rerun the previous step. The new image will be pulled because podman run has --pull always added near the end of the command.

The behaviour is consistent across all my composes. Here is a short censored one:

services:
  duckdnstest:
    restart: unless-stopped
    image: docker.io/linuxserver/duckdns
    container_name: duckdnstest
#    pull_policy: always
    hostname: duckdnstest

It won't actually yield a working duckdns container because the environment variables are omitted, but podman-compose up and down work as expected and the issue occurs before the container goes up anyway.

Expected behavior The 3rd step should add --pull always to the podman run command, or do something equivalent (e.g. podman pull before podman run).

Behaviour with pull_policy: always in the compose file is shown below. There may be slight differences in how the --pull-always arg is supposed to work, but the point is that a pull takes place, even if there is a local version of the image:

$ /home/keith/pcdevel/bin/podman-compose up -d --pull-always
podman-compose version: 1.0.6
['podman', '--version', '']
using podman version: 4.3.1
** excluding:  set()
['podman', 'ps', '--filter', 'label=io.podman.compose.project=minexample', '-a', '--format', '{{ index .Labels "io.podman.compose.config-hash"}}']
['podman', 'network', 'exists', 'minexample_default']
podman run --name=duckdnstest -d --label io.podman.compose.config-hash=63322e096752c747c6139433d1e1a583cb02b7790a268ab1cfcf5f55043a8964 --label io.podman.compose.project=minexample --label io.podman.compose.version=1.0.6 --label PODMAN_SYSTEMD_UNIT=podman-compose@minexample.service --label com.docker.compose.project=minexample --label com.docker.compose.project.working_dir=/tmp/minexample --label com.docker.compose.project.config_files=docker-compose.yml --label com.docker.compose.container-number=1 --label com.docker.compose.service=duckdnstest --net minexample_default --network-alias duckdnstest --hostname duckdnstest --pull always --restart unless-stopped docker.io/linuxserver/duckdns
Trying to pull docker.io/linuxserver/duckdns:latest...
Getting image source signatures
Copying blob f3a49a85e687 skipped: already exists
Copying blob fd3a0bb93880 skipped: already exists
Copying blob 85afcca2475a skipped: already exists
Copying blob fb9ff607e747 skipped: already exists
Copying blob 00bbf9c9837a skipped: already exists
Copying blob 8532028da3cf skipped: already exists
Copying blob 14fbb6a2c498 skipped: already exists
Copying config b66345217c done
Writing manifest to image destination
Storing signatures
ded3b09263cecb4597c9cba3d6d369fbd85d1897ee3d4aa259fb91b4d46c09fc
exit code: 0

Actual behavior The 3rd step will start up whatever old local image is available, if present. No error, warning, return code, or other indication is given that it didn't do what --pull-always suggests.

Behaviour shown below with pull_policy in the compose file commented out so the bug behaviour is present.

$ /home/keith/pcdevel/bin/podman-compose up -d --pull-always
podman-compose version: 1.0.6
['podman', '--version', '']
using podman version: 4.3.1
** excluding:  set()
['podman', 'ps', '--filter', 'label=io.podman.compose.project=minexample', '-a', '--format', '{{ index .Labels "io.podman.compose.config-hash"}}']
['podman', 'network', 'exists', 'minexample_default']
podman run --name=duckdnstest -d --label io.podman.compose.config-hash=594e3215c995c56e704481a232c0607891de8cb6847e3104b8adb5185f6da80a --label io.podman.compose.project=minexample --label io.podman.compose.version=1.0.6 --label PODMAN_SYSTEMD_UNIT=podman-compose@minexample.service --label com.docker.compose.project=minexample --label com.docker.compose.project.working_dir=/tmp/minexample --label com.docker.compose.project.config_files=docker-compose.yml --label com.docker.compose.container-number=1 --label com.docker.compose.service=duckdnstest --net minexample_default --network-alias duckdnstest --hostname duckdnstest --restart unless-stopped docker.io/linuxserver/duckdns
b3556088fa8b4d50274f6af772e23a5d2c3cee39889f3dd7f2ab34c71017715f
exit code: 0

Environment:

Additional context

podman-compose build may or may not have the same bug, but I am not familiar with it enough to find out.