Open DavidJaeck opened 2 weeks ago
@DavidJaeck yes, it's not idempotent, since Podman always loads the image and doesn't provide any indication whether it's already loaded or not. Probably it even can't say without loading it :shrug: We can't do here anything, unless you have ideas how to do it.
@sshnaidm I can confirm there is an issue with
subprocess.run(['podman', 'load', '--input', 'hello-world.tar'], capture_output=True, text=True)
podman usually returns
[david@cmt381428759805 modules]$ podman load --input hello-world.tar Getting image source signatures Copying blob 2114fc8b7058 skipped: already exists Copying config 5dd467fce5 done | Writing manifest to image destination Loaded image: quay.io/podman/hello:latest
The module sh does not seem to be affected by this issue:
import sh
output = sh.podman("load", "-i", "hello-world.tar", _ok_code=[0, 1], _err_to_out=True) # Merge stderr with stdout
print("Output:", output)
>>>Output: Getting image source signatures
Copying blob 2114fc8b7058 skipped: already exists
Copying config 5dd467fce5 done |
Writing manifest to image destination
Loaded image: quay.io/podman/hello:latest`
Maybe there is something in the enviroment of subprocess.run
I don't know what the implications of using sh.podman would be
@DavidJaeck sorry, I'm not sure what you mean. Can you elaborate please?
The cmd stderr for
/bin/bash podman load --input hello-world.tar
contains messages like
Copying blob 2114fc8b7058 skipped: already exists
The cmd stderr in python for
subprocess.run(['podman', 'load', '--input', 'hello-world.tar'], capture_output=True, text=True)
does not contain any hints on whether the image was changed - it only contains lines like
Copying blob sha256:869cfd058ffa32f9eec431858ea3b2ee81dfb2b54aee5d6fd9c8cb7ceb1d124f
The cmd stderr in python for
output = sh.podman("load", "-i", "hello-world.tar", _ok_code=[0, 1], _err_to_out=True)
just like the standard shell invocation contains:
Copying blob 2114fc8b7058 skipped: already exists
So there is an issue with subprocess.run Somehow one might get around it. Apparently using sh is not a viable alternative since it is not supported on windows.
@DavidJaeck OK, but how is it related to idempotency? Firstly, the blob is not the image, it's fine to have existing blobs when you are loading the completely new image. The output still doesn't tell you if it was there before or not. Secondly, you anyway need to load it to see.
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
I am not sure if this is a bug, or if I am using the module incorrectly. I am loading an image with podman_load. The load is successful, however the changed when status and sdt error lines seem incorrect. If I import the image twice I would expect the status to be "changed": false and I would expect the error line to state blobs are skipped because they already exist. However there always appears to be a change since the module is never realizing the blobs are already existent and can be skipped.
Steps to reproduce the issue:
1. ansible-playbook testplaybook.yml with file content
Describe the results you received: I receive status "changed": true and stderror lines
Describe the results you expected: I receive "changed": false and sdterror lines along the lines of
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 fromansible-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.): physical