-
Notifications
You must be signed in to change notification settings - Fork 122
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
Make image archive/save idempotent, using image id and repo tags as keys #500
Make image archive/save idempotent, using image id and repo tags as keys #500
Conversation
bdfd152
to
5ba45c8
Compare
8058322
to
4a73414
Compare
I've removed the 'do not merge' label. I attempted to add two I worked around that by base64-encoding the files and including them as a string literal. The files were generated by me using |
I would really avoid adding binary blobs to this repository. How about creating these files during the integration tests (by running |
One of the two tar files is very small (hello world is about 3kb). The other one is larger (about 3 mb) but I can find a smaller substitute, for example creating an image from Would two small files be adequate? Is there a way to exclude them from release/distribution packaging? The unit tests are easier and faster to run, and in principle, I think these tests belong there. They test parsing a file, as opposed to interacting with a service. Regenerating them each time also introduces variability into the test input; it's nice to have the same exact input across all versions of Python being tested. |
I would really avoid adding any kind of binary file, if not absolutely necessary.
They are faster to run, but they also are a big problem, since you are including copyrighted contents into this repository. Both the hello-world executable and busybox come with copyright and legal conditions attached.
I don't think this will be a problem. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a changelog fragment. Thanks.
6ff9156
to
ca15ddb
Compare
Changes:
|
You have a very strange commit list, I guess you should probably rebase to get rid of all the stray changes which do not belong into this PR. |
ffd76b6
to
b1b6618
Compare
Changes:
|
b1b6618
to
e40e415
Compare
Made one more docstring change to tickle the build after a transient network related failure. Ready for review. |
50ad5eb
to
fe71743
Compare
2402819
to
b52cd49
Compare
I'm now getting build failures which are timeouts waiting for the temporary docker registry to start. Made a whitespace change to tickle the build and it failed the same way (three times so far). I don't think this is related to accepting your import change suggestion, but I rebased right away. Looking at the CI log, I suspect the registry container is failing to stay running (the previous successful task is a start request), but there isn't any log output from the registry container in the CI log to see why. |
967ba1a
to
1d4782f
Compare
This might be caused by ansible/ansible#78550. Simply ignore that failure for now. |
Now there's a conflict due to the other PR being merged. After rebasing with the latest |
1d4782f
to
7353fbb
Compare
I'm updating the docstring style in this PR also, it's not committed yet. I'll drop a message here once the build is green and I've looked over the code one last time. |
7353fbb
to
85b2a94
Compare
Build is green. I did miss one triple-quote to single quote in a test_docker_image.py If that doesn't concern you, I don't see anything else to change. |
@iamjpotts thanks a lot for your contribution! |
SUMMARY
The
docker_image
component supports saving images to a tar file, similar todocker image save
command. When adocker_image
archive task is run repeatedly, it recreates the file every time.After this change, the task will compare the Docker image ID of the archive file (if any) vs the image stored in the Docker Engine, and if they are the same, the archive file is left untouched.
ISSUE TYPE
COMPONENT NAME
docker_image
used witharchive_path
ADDITIONAL INFORMATION
Consider a scenario with two servers (
localhost
andtarget
), where an Ansible playbook synchronizes images to a target server.localhost
usesdocker_load
witharchive_path
to export an image to a taransible.builtin.file
synchronizes the directory with the tar file on localhost with a target server directorydocker_load
imports tar file on target server to target server's docker engineCurrently, this workflow regenerates the tar files over and over again, resending them to the target server each time.
After this change, Step 1 only exports the tar files once, until the source image changes, preventing the network copy from
localhost
totarget
on subsequent runs.Export playbook
Import playbook
Output, without this PR, run 1 of 2.
Output, without this PR, run 2 of 2. Shows
changed
againOutput, with this PR, run 1 of 2.
Output, with this PR, run 2 of 2. Shows
ok
on second run.