-
Notifications
You must be signed in to change notification settings - Fork 101
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
[Bug]: cache doesnt work, if client tries to pull a docker image with registry:tag@digest notation #2584
Comments
@jkroepke this is because zot is expecting a tag-based pull as the common use case. We will look at this. Thanks. |
docker pull zot/kube-state-metrics/kube-state-metrics@sha256:ca0b12d75f673fa03f9a69aa30fa904c52525251395a8e7d813f23eca7a3dbfe @jkroepke can you try this instead? dropping the tag entirely? |
Doesn't work, too.
Once Once zot is restarted (which clears the cache), the pull does not work anymore. |
Hi @jkroepke, can you please share the sync configuration you have, and the logs produced by zot when making the call Note in the previous comment you mentioned you use Still this doesn't explain why the first Another thing to try out is to use skopeo to request |
Hey @andaaron I shared the whole zot configuration on the first post.
|
Original Registry:
zot Registry:
You are right. Looking closer to the pull logs of the docker client, the digest will be used for pull, even both is defined.
|
@jkroepke than you for the details. Can you please send the zot server-side logs from around the time the pull is done? Also based on the config, it is really strange the image is no longer found when zot is restarted given storage is local. May be related to "commit=False" in the settings, but I don't remember the use case for that. @rchincha, why do we have this commit setting? L.E. Normally the images are stored under your storage root dir /var/lib/registry/kube-state-metrics/kube-state-metrics/, and should be accessible when you restart the service |
Thats expected, because the local storage will be deleted by Kubernetes. ( Server logs:
Server logs (using pull by tag):
|
OK, I assumed you wanted the images to be available in zot storage after a zot restart. |
Yeah, thats why I'm working on #2223 |
Based on the logs it should have been copied to a local temporary folder ("/var/lib/registry/kube-state-metrics/kube-state-metrics/.sync/ef05c0e1-1a96-4102-8404-0e26522b2188/kube-state-metrics/kube-state-metrics"), but in the next function call it doesn't find it there. We need to investigate this further. |
I did some digging, reproduced, and I think I found the root cause:
This is a docker media type: |
I think we could add a "fix" in zot to return the files in OCI format to the client, but they wouldn't have the same digests, and if the local docker does any validation on the response body digests it would find the digest mismatch. |
This setting makes sure that data is actually persisted on the disk before responding back to the client, else it could just be in un-flushed buffers which is faster but exposes to data losses. |
Not sure, if that an good approach. I guess it would also break signatures and provenance? skoepo has an option to preserve digests (https://github.com/containers/skopeo/blob/5af7b5dba12ce9a157e96e030d477d5946e5fb27/cmd/skopeo/copy.go#L87) In background, it using the flag provide by github.com/containers/image Why it cant be used at zot? |
As far as I can tell that is an option to fail the operation in case the digests cannot be preserved. You are right about signatures and other referrers. See also #724 |
hi, is there a plan to fix this "bug" ? we are using zot as a pull cache mirror, but some helm chart is using tag@digest syntax which breaks image pull process. does this pr #2714 means zot can skip OCI convert step when mirror from docker only registry ? |
It is not a bug, as we didn't support docker mediatypes in the first place. |
How about just pass the remote response directly to the client when use pull with |
zot version
v2.1.0-rc2
Describe the bug
Some helm chart like ingress-nginx has both tag an digest defined in image spec. zot reports
name unknown: repository name not known to registry
, when configured as pull-through cache using the cache extensionTo reproduce
Details
docker pull zot/kube-state-metrics/kube-state-metrics:v2.12.0@sha256:ca0b12d75f673fa03f9a69aa30fa904c52525251395a8e7d813f23e
Expected behavior
It should pull the image
Screenshots
No response
Additional context
Pull with the without digest works fine. Once the image is cached, pull with digest works.
The text was updated successfully, but these errors were encountered: