-
-
Notifications
You must be signed in to change notification settings - Fork 152
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
Labels
bug/idempotency
Bug related to idempotency of modules
Comments
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]>
Is there any progress or required some help? |
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
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
When using the
mount
parameter forpodman_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:
But the following re-creates the container on every run even when it already exists:
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
Output of
ansible --version
:Output of
podman version
:Output of
podman info --debug
:Package info (e.g. output of
rpm -q podman
orapt list podman
):Playbok you run with ansible (e.g. content of
playbook.yaml
):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
Additional environment details (AWS, VirtualBox, physical, etc.):
The text was updated successfully, but these errors were encountered: