Open JohnBucherBlue opened 2 months ago
JohnBucherBlue
commented
1 month ago Any updates on this issue? I'm curious if this a known problem to other users OR if this has been recreated yet.
If you need any additional information or steps from me, feel free to reach out. Thanks!
Vad1mo
commented
1 month ago I can verify the issue, we have seen and reproduced it as well.
stonezdj
commented
1 month ago No multi arch env to verify this bug
JohnBucherBlue
commented
1 month ago @stonezdj Correct me if I am wrong, but I don't believe you need a multi-arch environment to test this functionality/issue, I believe a normal Harbor deployment/env should suffice.
If you have a normal deployment of Harbor then a user can pull images with different architectures through its proxy-cache. By adding the following piece to your docker pull command, ex: "--platform linux/arm64" you can force a specific architecture pull even if your machine doesn't support it. The user doesn't even necessarily need to be able to run/use these resulting images, but the pulling of these multi-arch images through the proxy-cache will cause Harbor creations of artifacts like the OCI Image Index and should demonstrate the issues we're running into when additional architectures are pulled.
Let me know if you have any issues or need any additional information from our end. Thanks!
yaohwu
commented
2 days ago looking forward to this feature
If you are reporting a problem, please make sure the following information are provided:
Expected behavior and actual behavior: We are currently utilizing Harbor’s proxy-cache capability. Currently, we are running into issues where when pulling images with the same tag/version, but different architectures, it won’t “combine” the two images under the same tag/OCI Image Index.
Steps to reproduce the problem: Using a redis image as an example, I first pulled an image with the tag: 7.4.0 and specified the platform: “linux/arm64” using the following command:
“docker pull --platform linux/arm64 [server name]/ext.hub.docker.com/library/redis:7.4.0”
This created the following item in the Harbor UI. It first appeared as an untagged artifact immediately upon creation and after approximately 7 minutes an OCI Image Index was created and the original untagged artifact was put inside of that “folder”. This delayed creation and tagging is also an issue we are encountering, so insights into how to make this OCI Index creation and tagging more immediate would be greatly appreciated.
Clicking inside of that OCI Index folder I see our image and the architecture that we specified.
Which looks as expected => We now have a structure that mirrors Docker Hub’s where we have a tag/version at the top level, and all of the various OS/ARCH options below that.
But when I try to pull a different architecture for the same tag through the proxy-cache (in this case: amd64), it does not add this additional architecture under the previously created 7.4.0 tag/OCI Image Index like I would have expected. Running the following command:
“docker pull --platform linux/amd64 [server name]/ext.hub.docker.com/library/redis:7.4.0”
This pull created a new item on the top level of the repository.
Clicking into that new artifact’s SHA, you can see that it has all of the information that it should need to determine its OS/ARCH and version:
And yet it did not get added under our first item’s OCI Image Index. Instead it got created as a new artifact at the top level of the repository and didn’t receive a tag. Not receiving a tag is likely because our first item got the 7.4.0 tag, and since the tag is unique, our second item didn’t get a tag.
Versions: Please specify the versions of following systems.
Additional context: This secondary pull of an architecture that already has an OCI Index and tag also doesn’t seem to “fire” a webhook notification for a new image as we would expect as well. This may be a secondary effect of the issues highlighted above, where not having a tag or not going under the proper OCI Index might be the reason for this webhook not to fire when we would have expected it to.
Since Harbor is handling the creation of these items, it is hard to deduce or debug why these two images aren’t combining under the same OCI Index. Any insights into what is going wrong or how to best debug or find logs would be greatly appreciated!