Timestamps in 'image list' inconsistent with 'image history' #14456
Labels
locked - please file new issue/PR
Assist humans wanting to comment on an old issue or PR with locked comments.
Comments
|
One would think this is a conversion error. podman image list and podman history converting the timestamp differently and potentially one rounding up, while the other rounds down? |
|
I'll take a look |
That's a really good suggestion - I had forgotten about fractional time_t. Does anyone know how to actually show that? Command completion shows me all sorts of promising fields, but none of them actually work: $ bin/podman image history --format '{{.Created.' quay.io/libpod/testimage:20210610
{{.Created.Add -- This is a function and requires 1 argument
{{.Created.AddDate -- This is a function and requires 3 arguments
{{.Created.After -- This is a function and requires 1 argument
{{.Created.AppendFormat -- This is a function and requires 2 arguments
{{.Created.Before -- This is a function and requires 1 argument
{{.Created.Equal -- This is a function and requires 1 argument
{{.Created.Format -- This is a function and requires 1 argument
{{.Created.In -- This is a function and requires 1 argument
{{.Created.Round -- This is a function and requires 1 argument
{{.Created.Sub -- This is a function and requires 1 argument
{{.Created.Truncate -- This is a function and requires 1 argument
{{.Created.Day}} {{.Created.Month}} {{.Created.Unix}}
{{.Created.Hour}} {{.Created.Nanosecond}} {{.Created.Weekday}}
{{.Created.IsZero}} {{.Created.Second}} {{.Created.YearDay}}
{{.Created.Local. {{.Created.String}} {{.Created.Year}}
{{.Created.Location}} {{.Created.UTC.
{{.Created.Minute}} {{.Created.UnixNano}}
$ bin/podman image history --format '{{.Created.UnixNano}}' quay.io/libpod/testimage:20210610
Error: template: history:1:21: executing "history" at <.Created.UnixNano>: can't evaluate field UnixNano in type string |
|
I got it ... I'll spin up a PR but I am unable to create a reproducer. |
vrothberg
added a commit
to vrothberg/libpod
that referenced
this issue
Jun 3, 2022
As shown in containers#14456, the `.CreatedAt` fields for `image list` and of `image history` can differ by one. The discussed theory is that the off-by-one is caused by rounding. Indeed, the field of `image list` is reformatted. `image history` is returning the UNIX time; just as the `.CreatedAt` field should. I am unable to create a reproducer for the issue but double-checked what the docker client does: return the UNIX time. [NO NEW TESTS NEEDED] Fixes: containers#14456 Signed-off-by: Valentin Rothberg <[email protected]>
|
I gave it a shot in #14476 but I should have taken a closer look at the image. In short:
The image was created before the first layer. Ultimately, it looks a fart in the tool that built the image. I suggest to either change this test or pin it to an image that is known to work (via --arch=xxx). |
|
okay, got it: the image $ bin/podman pull -q --arch=ppc64le $iii
$ skopeo inspect --config containers-storage:$iii|gron|grep -w created|column -t -s= -c 60
json.created "2021-06-10T18:55:59.923932059Z"; <------ this
json.history[0].created "2021-06-10T18:55:59.669999782Z";
json.history[1].created "2021-06-10T18:55:59.881513564Z";
json.history[2].created "2021-06-10T18:55:59.881544593Z";
json.history[3].created "2021-06-10T18:55:59.881556911Z";
json.history[4].created "2021-06-10T18:55:59.901991948Z";
json.history[5].created "2021-06-10T18:56:00.030467643Z"; <----- is not the same as thisI think I could fix this by building a new testimage using the |
edsantiago
added a commit
to edsantiago/libpod
that referenced
this issue
Jun 15, 2022
Changes:
- use --timestamp option to produce 'created' stamps
that can be reliably tested in the image-history test
- podman now supports manifest & multiarch run, so we
no longer need buildah
- bump up base alpine & busybox images
This turned out to be WAY more complicated than it should've been,
because:
- alpine 3.14 fixed 'date -Iseconds' to include a colon in
the TZ offset ("-07:00", was "-0700"). This is now consistent
with GNU date's --iso-8601 format, yay, so we can eliminate
a minor workaround.
- with --timestamp, all ADDed files are set to that timestamp,
including the custom-reference-timestamp file that many tests
rely on. So we need to split the build into two steps. But:
- ...with a two-step build I need to use --squash-all, not --squash, but:
- ... (deep sigh) --squash-all doesn't work with --timestamp (containers#14536)
so we need to alter existing tests to deal with new image layers.
- And, long and sordid story relating to --rootfs. TL;DR that option
only worked by a miracle relating to something special in one
specific test image; it doesn't work with any other images. Fix
seems to be complicated, so we're bypassing with a FIXME (containers#14505).
And, unrelated:
- remove obsolete skip and workaround in run-basic test (dating
back to varlink days)
- add a pause-image cleanup to avoid icky red warnings in logs
Fixes: containers#14456
Signed-off-by: Ed Santiago <[email protected]>
github-actions
bot
added
the
locked - please file new issue/PR
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Reported by multiarch team in their gitlab tracker
On multiarch, one of the
podman image historytests is failing:Reason: that test runs
podman image list $IMAGEandpodman image history $IMAGE, and assumes that the first line ofhistoryshould match the timestamp oflist. It does not. Neither does it match the last line.Reproducer (well, not really, but a one-liner that demonstrates the problem):
Note that sometimes the
image listtimestamp matches the first line fromhistory, and sometimes the last.Test code:
podman/test/system/110-history.bats
Lines 58 to 69 in e60c416
Questions:
podman image listget its timestamp from?The text was updated successfully, but these errors were encountered: