Skip to content
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

Stereoscope pulls different images when using docker: vs registry: from multi-platform images #149

Closed
Hritik14 opened this issue Dec 7, 2022 · 0 comments · Fixed by #152 or #189
Closed
Assignees
Labels
bug Something isn't working

Comments

@Hritik14
Copy link

Hritik14 commented Dec 7, 2022

What happened:
On an arm machine, stereoscope produces different results when pulling a multi-platform image using docker scheme vs registry scheme.
The docker scheme correctly infers the host architecture and pulls the correct matching image whereas the registry scheme pulls only amd64/linux image when platform is not explicitly provided.

What you expected to happen:
The platform for both images should be the same, preferably the host platform.
If inference of platform is not intended in an OCI/registry source, this difference should be verbose in debug logs or in documentation.

How to reproduce it (as minimally and precisely as possible):
On an arm machine, registry scheme yields an x86 image (incorrectly)

; go run examples/basic.go registry:rust:1.42-slim-buster | grep binutils-x86
[0000] DEBUG image: source=OciRegistry location=rust:1.42-slim-buster
[0000] DEBUG pulling image info directly from registry image="rust:1.42-slim-buster"
[0000] DEBUG no registry credentials configured, using the default keychain
[0003] DEBUG image metadata: digest=sha256:165a37f9b454c1b000732bc6fb31edb6710818f6096796e7951a1e91cafa758d mediaType=application/vnd.docker.distribution.manifest.v2+json tags=[]
[0003] DEBUG layer metadata: index=0 digest=sha256:b60e5c3bcef2f42ec42648b3acf7baf6de1fa780ca16d9180f3b4a3f266fe7bc mediaType=application/vnd.docker.image.rootfs.diff.tar.gzip
[0005] DEBUG layer metadata: index=1 digest=sha256:508d8706fc1db20449e5e0fe22c65e1cce8ee30d062c5357f7e81f22cb8c3441 mediaType=application/vnd.docker.image.rootfs.diff.tar.gzip
 ...
    /usr/share/doc/binutils-x86-64-linux-gnu
 ...

On the same machine, docker scheme yields an arm image (correctly)

; go run examples/basic.go docker:rust:1.42-slim-buster | grep binutils-aarch64
[0000] DEBUG image: source=DockerDaemon location=rust:1.42-slim-buster
[0008] DEBUG image metadata: digest=sha256:8dc750c34fb3e46a4585e531416d995592fd7ca89630be76cca23ce1da26391f mediaType=application/vnd.docker.distribution.manifest.v2+json tags=[rust:1.42-slim-buster]
[0008] DEBUG layer metadata: index=0 digest=sha256:67d3a85d42a2b4ae3ca54ff7b6225bb136fbe0fa5732d9c5143470f13470bbde mediaType=application/vnd.docker.image.rootfs.diff.tar.gzip
[0008] DEBUG layer metadata: index=1 digest=sha256:081726014efb2e4d440405aee79d2cca3966c3fc965ce2cee13fd972c907e953 mediaType=application/vnd.docker.image.rootfs.diff.tar.gzip
    /usr/share/doc/binutils-aarch64-linux-gnu
...

Anything else we need to know?:
DaemonImageProvider infers host platform and pulls the correct image whereas
RegistryImageProvider uses go-containerregistry which defaults to amd64/linux when platform is missing rather than inferring the host platform.
See also:

Environment:

  • OS: MacOS Monterey, M1 Pro.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Archived in project
2 participants