docker/save: stable timestamp for blobs/digest dir#51365
Conversation
|
Thanks! ❤️ This test will also need adjustment: moby/integration/image/save_test.go Line 87 in 560dfb1 |
Oops thanks. Will address! |
Nice catch! I saw the PR (and ticket) and thought "didn't we fix that?", but that makes sense! |
|
Hey @thaJeztah, I'm just coming back to update that test to check all the members of the tar aren't newer than the img.Created (or 0, in the containerd case). |
|
I think we might be missing something - the test didn't fail and it should I think? |
|
@vvoland The test doesn't fail as it only checks that the OCI manifest has a timestamp of 0 (which it did previously). None of the other members of the tar are actually checked. |
|
moby/integration/image/save_test.go Line 77 in 560dfb1 Doesn't it check the image In the test, we should just remove the branching and make sure that in both cases the ModTime is moby/integration/image/save_test.go Lines 83 to 88 in 560dfb1 |
|
Sorry @vvoland, I don't know the terminology very well, does |
|
No, it's the image config https://github.com/opencontainers/image-spec/blob/main/config.md referenced by the legacy It's written in: moby/daemon/internal/image/tarexport/save.go Line 490 in 3287abc |
|
But, we should probably just change that test so it verifies that all files inside the tar have mtime |
|
@vvoland Ah thanks for clarifying. Sorry for the confusion here! This MR only fixes the contemporary timestamp on the In the spirit of the existing code (that attempts to maintain the mtime of img.Created) I was thinking the test should:
But do you think we should instead expand the scope here to ignore img.Created and always reset mtime for all members in the tar? |
3990e8a to
daa5188
Compare
|
I have unapplied the patch in this MR and updated the test as I suggested above. Running this test without the containerd storage driver, I can demonstrate the updated test catches the bug described by #51364. That is, the test identifies the contemporary timestamp on the The containerd case passes as expected as all the timestamps appear to be sanitised to mtime 0 anyway: Reapplying the patch in this MR, the test now passes under the overlay2 condition as the I've updated the commit in this MR to include the changes to the test. Note that I temporarily added a log line to the test to indicate the tar member name and mtime, just to show to you here that all tar members are checked and to emphasise the existing difference in behaviour between the two storage drivers; this log line is not in the MR. I believe this MR now correctly tests for and fixes the unexpected behaviour described by #51364. I'd suggest further discussion on whether the mtimes should always be 0 is a new issue, as the existing code clearly indicates an intention to maintain img.Created on some of the tar members, for reasons unknown to me. I'd be happy to make this change and submit a new MR to change mtime to 0 in all cases if that is desired. |
ef3e08b to
34af3d7
Compare
Writing the OCI manifest file to the blobs/digest dir will update the directory mtime, producing a tar file containing a member with a contemporary mtime. Exported tars for the same image will therefore have different checksums. Although this was previously addressed by overriding the mtime manually to 0, this was done before the OCI manifest file was written. This change simply moves the call to system.Chtimes to set the mtime of the blobs/digest directory to 0 after writing the OCI manifest file. This commit also updates the TestSaveCheckTimes integration test to check the mtime of all members in the exported tar to ensure that all mtime are not newer than img.Created or 0 (depending on whether the containerd-snapshotter is disabled or enabled, respectively). Signed-off-by: Sam Nicholls <sam.nicholls@nanoporetech.com>
34af3d7 to
668b546
Compare
vvoland
left a comment
There was a problem hiding this comment.
LGTM; still think we should drop the old behavior and just set mtime for all files to 0, just like the containerd implementation does
Yeah, I think that would make sense; can be done in a follow-up I guess? |
|
Yep, fine for a follow up! @SamStudio8 feel free to continue in a new issue/PR if you're still interested in this one. |
|
@vvoland @thaJeztah Thanks both for your time!
Happy to pick this up, see you on the next MR. |
- What I did
Fixes #51364: files generated by
docker savewith theoverlay2storage driver are now consistent across time.- How I did it
This change moves the call to
system.Chtimesto set the mtime of the blobs/digest directory to 0 after writing the OCI manifest file.- How to verify it
Generate a tar with
docker saveafter applying the patch:- Human readable description for the release notes
- A picture of a cute animal (not mandatory but encouraged)
Please enjoy this picture of Daisy Doodle, our toy poodle: