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_container: mount breaks idempotency #355

Closed
smessmer opened this issue Dec 14, 2021 · 2 comments · Fixed by #753
Closed

podman_container: mount breaks idempotency #355

smessmer opened this issue Dec 14, 2021 · 2 comments · Fixed by #753
Labels
bug/idempotency Bug related to idempotency of modules

Comments

@smessmer
Copy link

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

/kind bug

Description

When using the mount parameter for podman_container, the container gets recreated on every run even when there were no changes.

Steps to reproduce the issue:

The following runs fine and doesn't re-create the container if it already exists:

- name: POD registry CONTAINER registry
  containers.podman.podman_container:
    name: registry-registry
    image: registry:2
    pod: registry
    state: started
    network: registry-network
    volume:
    - /opt/containers/registry/config.v0.yml:/etc/docker/registry/config.yml
    - registry-data:/var/lib/registry
    - registry-log:/var/log

But the following re-creates the container on every run even when it already exists:

- name: POD registry CONTAINER registry
  containers.podman.podman_container:
    name: registry-registry
    image: registry:2
    pod: registry
    state: started
    network: registry-network
    mount:
    - "type=bind,source=/opt/containers/registry/config.v0.yml,destination=/etc/docker/registry/config.yml,ro=true"
    volume:
    - registry-data:/var/lib/registry
    - registry-log:/var/log

Describe the results you received:

Describe the results you expected:

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

Version of the containers.podman collection:
Either git commit if installed from git: git show --summary
Or version from ansible-galaxy if installed from galaxy: ansible-galaxy collection list | grep containers.podman

containers.podman             1.8.2  

Output of ansible --version:

ansible [core 2.12.1]
  config file = /home/heinzi/projects/dockerserver/host/ansible.cfg
  configured module search path = ['/home/heinzi/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/heinzi/projects/dockerserver/host/venv/lib/python3.9/site-packages/ansible
  ansible collection location = /home/heinzi/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/heinzi/projects/dockerserver/host/venv/bin/ansible
  python version = 3.9.5 (default, May 11 2021, 08:20:37) [GCC 10.3.0]
  jinja version = 3.0.3
  libyaml = True

Output of podman version:

podman version 3.0.1

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.19.6
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: 'conmon: /usr/bin/conmon'
    path: /usr/bin/conmon
    version: 'conmon version 2.0.25, commit: unknown'
  cpus: 4
  distribution:
    distribution: debian
    version: "11"
  eventLogger: journald
  hostname: [redacted]
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.10.0-9-amd64
  linkmode: dynamic
  memFree: 16020426752
  memTotal: 16786501632
  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
    selinuxEnabled: false
  slirp4netns:
    executable: ""
    package: ""
    version: ""
  swapFree: 0
  swapTotal: 0
  uptime: 1h 26m 57.97s (Approximately 0.04 days)
registries: {}
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 2
    paused: 0
    running: 2
    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: 3
  runRoot: /run/containers/storage
  volumePath: /var/lib/containers/storage/volumes
version:
  APIVersion: 3.0.0
  Built: 0
  BuiltTime: Thu Jan  1 01:00:00 1970
  GitCommit: ""
  GoVersion: go1.15.9
  OsArch: linux/amd64
  Version: 3.0.1

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

Listing... Done
podman/stable,now 3.0.1+dfsg1-3+b2 amd64 [installed]

Playbok you run with ansible (e.g. content of playbook.yaml):

(paste your output here)

Command line and output of ansible run with high verbosity

Please NOTE: if you submit a bug about idempotency, run the playbook with --diff option, like:

ansible-playbook -i inventory --diff -vv playbook.yml

--- before
+++ after
@@ -1 +1 @@
-volume - ['/opt/containers/registry/config.v0.yml:/etc/docker/registry/config.yml']
+volume - []

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

@sshnaidm sshnaidm added the bug/idempotency Bug related to idempotency of modules label Dec 27, 2021
rubiksdot pushed a commit to rubiksdot/ansible-podman-collections that referenced this issue Jul 10, 2022
This is a fix for bug containers#355.

This compares the arguments podman recieved for the currently existing
container with the (effective) arguments to come.

This approach was taken over parsing Mounts from inspect because:

1. This line from https://github.com/containers/podman/blob/e084f0ee1e1ded564110e84eefca9f18b5669adf/libpod/container_inspect.go#L224
   regarding inspect's Mount value:

   "Only includes user-specified mounts. Only includes bind mounts and named volumes, not tmpfs volumes."

   Thus an incomplete solution would result.

2. The code required to parse so that it could be compared with the
   stuff to come was getting silly-level complex.

3. Anonymous volumes were impossible to decipher as both Name and
   Source are filled in with the podman-generated values.

Thus we compare the arguments podman create was run with to make the
existing container with the closest values to those arguments in the
new config.

This resulted in simpler code that takes care of the issue of anonymous
volumes.

The downside is that if someone moves, say, a tmpfs from mount to tmpfs
(or vice versa) that would reult in exactly the same result this will
be considered a different config. This can (possibly) be fixed if and
when it becomes an actual issue.

Signed-off-by: Andrew <[email protected]>
rubiksdot pushed a commit to rubiksdot/ansible-podman-collections that referenced this issue Jul 10, 2022
This is a fix for bug containers#355.

This compares the arguments podman recieved for the currently existing
container with the (effective) arguments to come.

This approach was taken over parsing Mounts from inspect because:

1. This line from https://github.com/containers/podman/blob/e084f0ee1e1ded564110e84eefca9f18b5669adf/libpod/container_inspect.go#L224
   regarding inspect's Mount value:

   "Only includes user-specified mounts. Only includes bind mounts and named volumes, not tmpfs volumes."

   Thus an incomplete solution would result.

2. The code required to parse so that it could be compared with the
   stuff to come was getting silly-level complex.

3. Anonymous volumes were impossible to decipher as both Name and
   Source are filled in with the podman-generated values.

Thus we compare the arguments podman create was run with to make the
existing container with the closest values to those arguments in the
new config.

This resulted in simpler code that takes care of the issue of anonymous
volumes.

The downside is that if someone moves, say, a tmpfs from mount to tmpfs
(or vice versa) that would reult in exactly the same result this will
be considered a different config. This can (possibly) be fixed if and
when it becomes an actual issue.

Signed-off-by: Andrew <[email protected]>
sshnaidm pushed a commit to sshnaidm/ansible-podman-collections that referenced this issue Feb 26, 2023
This is a fix for bug containers#355.

This compares the arguments podman recieved for the currently existing
container with the (effective) arguments to come.

This approach was taken over parsing Mounts from inspect because:

1. This line from https://github.com/containers/podman/blob/e084f0ee1e1ded564110e84eefca9f18b5669adf/libpod/container_inspect.go#L224
   regarding inspect's Mount value:

   "Only includes user-specified mounts. Only includes bind mounts and named volumes, not tmpfs volumes."

   Thus an incomplete solution would result.

2. The code required to parse so that it could be compared with the
   stuff to come was getting silly-level complex.

3. Anonymous volumes were impossible to decipher as both Name and
   Source are filled in with the podman-generated values.

Thus we compare the arguments podman create was run with to make the
existing container with the closest values to those arguments in the
new config.

This resulted in simpler code that takes care of the issue of anonymous
volumes.

The downside is that if someone moves, say, a tmpfs from mount to tmpfs
(or vice versa) that would reult in exactly the same result this will
be considered a different config. This can (possibly) be fixed if and
when it becomes an actual issue.

Signed-off-by: Andrew <[email protected]>
sshnaidm pushed a commit to sshnaidm/ansible-podman-collections that referenced this issue Apr 1, 2023
This is a fix for bug containers#355.

This compares the arguments podman recieved for the currently existing
container with the (effective) arguments to come.

This approach was taken over parsing Mounts from inspect because:

1. This line from https://github.com/containers/podman/blob/e084f0ee1e1ded564110e84eefca9f18b5669adf/libpod/container_inspect.go#L224
   regarding inspect's Mount value:

   "Only includes user-specified mounts. Only includes bind mounts and named volumes, not tmpfs volumes."

   Thus an incomplete solution would result.

2. The code required to parse so that it could be compared with the
   stuff to come was getting silly-level complex.

3. Anonymous volumes were impossible to decipher as both Name and
   Source are filled in with the podman-generated values.

Thus we compare the arguments podman create was run with to make the
existing container with the closest values to those arguments in the
new config.

This resulted in simpler code that takes care of the issue of anonymous
volumes.

The downside is that if someone moves, say, a tmpfs from mount to tmpfs
(or vice versa) that would reult in exactly the same result this will
be considered a different config. This can (possibly) be fixed if and
when it becomes an actual issue.

Signed-off-by: Andrew <[email protected]>
@whoamiUNIX
Copy link

Is there any progress or required some help?

@betelgeuse
Copy link

The fix for this seems to be under work in the pull request #448

sshnaidm pushed a commit to sshnaidm/ansible-podman-collections that referenced this issue Mar 28, 2024
This is a fix for bug containers#355.

This compares the arguments podman recieved for the currently existing
container with the (effective) arguments to come.

This approach was taken over parsing Mounts from inspect because:

1. This line from https://github.com/containers/podman/blob/e084f0ee1e1ded564110e84eefca9f18b5669adf/libpod/container_inspect.go#L224
   regarding inspect's Mount value:

   "Only includes user-specified mounts. Only includes bind mounts and named volumes, not tmpfs volumes."

   Thus an incomplete solution would result.

2. The code required to parse so that it could be compared with the
   stuff to come was getting silly-level complex.

3. Anonymous volumes were impossible to decipher as both Name and
   Source are filled in with the podman-generated values.

Thus we compare the arguments podman create was run with to make the
existing container with the closest values to those arguments in the
new config.

This resulted in simpler code that takes care of the issue of anonymous
volumes.

The downside is that if someone moves, say, a tmpfs from mount to tmpfs
(or vice versa) that would reult in exactly the same result this will
be considered a different config. This can (possibly) be fixed if and
when it becomes an actual issue.

Signed-off-by: Andrew <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug/idempotency Bug related to idempotency of modules
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants