This repository has been archived by the owner on Nov 1, 2022. It is now read-only.
fluxctl list-images show up with timestamp of 01 Jan 70 00:00 UTC #1797
Comments
|
Here is the flux logs with registry trace logs enabled. |
|
Thanks for taking the time to log this issue, with extra detail @chriscorn-takt. The timestamps are Unix time = 0, which makes me think the results are empty (structs are initialised with "zero" values in Go). But to rule out an alternative, would you confirm that the actual images have timestamps -- you can do this by inspecting one of them: Assuming they are empty values, I wonder how they got there. I would expect that they can only be empty if the fetch resulted in an error -- and it should have recorded the fact of that error, and be reporting it back. OK, so something to try: if you restart memcached, it will force fluxd to repopulate it with image metadata. Then we'll see more in the logs about the results it gets trying to fetch from the image registry. |
|
Great catch @squaremo . The images do indeed boot however, and come back fine. |
|
Oh wow, I did not expect the timestamps to genuinely be zero! How do you build them? Could it be that they are built in VMs that don't have the clock set, or something along those lines? One thing we could do to help is let people override the build time with an image label (there are standard labels for that sort of thing). |
|
It looks like we have an internal requirement for the docker image create time to be set to essentially 0. So, it is by design. Unfortunately, my docker image tags are simply a commit hash. so, image auto updating may not work for me. thanks for your assistance. |
hiddeco
added a commit
that referenced
this issue
Apr 29, 2019
This adds support for overwriting the image created at timestamp with labels which are set during build. Supported labels (for now) are the Open Container Image (OCI) spec[1] and the (legacy) Label Schema (LS) spec[2]. We prioritize OCI over LS, with a fallback to the CreatedAt. This should serve a wide range of users who either have internal rules for image builds (e.g. timestamp set to null as reported in #1797) or want a stable reliable pointer they can have control over (#746, #891). [1]: https://github.com/opencontainers/image-spec/blob/master/annotations.md#pre-defined-annotation-keys [2]: http://label-schema.org/rc1/#build-time-labels
hiddeco
added a commit
that referenced
this issue
May 1, 2019
This adds support for overwriting the image created at timestamp with labels which are set during build. Supported labels (for now) are the Open Container Image (OCI) spec[1] and the (legacy) Label Schema (LS) spec[2]. We prioritize OCI over LS, with a fallback to the CreatedAt. This should serve a wide range of users who either have internal rules for image builds (e.g. timestamp set to null as reported in #1797) or want a stable reliable pointer they can have control over (#746, #891). [1]: https://github.com/opencontainers/image-spec/blob/master/annotations.md#pre-defined-annotation-keys [2]: http://label-schema.org/rc1/#build-time-labels
hiddeco
added a commit
that referenced
this issue
May 9, 2019
This adds support for overwriting the image created at timestamp with labels which are set during build. Supported labels (for now) are the Open Container Image (OCI) spec[1] and the (legacy) Label Schema (LS) spec[2]. We prioritize OCI over LS, with a fallback to the CreatedAt. This should serve a wide range of users who either have internal rules for image builds (e.g. timestamp set to null as reported in #1797) or want a stable reliable pointer they can have control over (#746, #891). [1]: https://github.com/opencontainers/image-spec/blob/master/annotations.md#pre-defined-annotation-keys [2]: http://label-schema.org/rc1/#build-time-labels
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
While trying view images, all images end up with an impossible timestamp. I am using the flux docker image quay.io/weaveworks/flux:1.10.1 .
The text was updated successfully, but these errors were encountered: