ctr: ctr images import --all-platforms: fix unpack
#11229
Conversation
Fix issue 11228
`ctr images import --all-platforms` w/o `--local` was failing due to
`unable to initialize unpacker: no unpack platforms defined` error.
W/ `--local`, it unpacks the layers for the strict-default platform.
Now `ctr images import --all-platforms` w/o `--local` unpacks the layers
for the non-strict default platform.
This behavior still differs from `--local`.
i.e., on an arm64 host, arm/v{5,6,7} layers are unpacked too.
Signed-off-by: Akihiro Suda <[email protected]>
AkihiroSuda
added
the
cherry-pick/2.0.x
| @@ -146,33 +145,26 @@ If foobar.tar contains an OCI ref named "latest" and anonymous ref "sha256:deadb | |||
| opts = append(opts, image.WithNamedPrefix(prefix, overwrite)) | |||
| } | |||
|
|
|||
| var platSpec ocispec.Platform | |||
There was a problem hiding this comment.
(The variable was renamed for clarity)
| // for compatibility with --local. | ||
| // | ||
| // This is still not fully compatible with --local, which only unpacks | ||
| // the strict-default platform layers. |
There was a problem hiding this comment.
(The transfer API should support specifying a strict platform matcher, but it is beyond the scope of this PR)
| // Only when all-platforms not specified, we will check platform value | ||
| // Implicitly if the platforms is empty, it means all-platforms | ||
| // Even with --all-platforms, only the default platform layers are unpacked, | ||
| // for compatibility with --local. |
There was a problem hiding this comment.
(Compatibility is out of the scope of ctr, but we cannot ignore that fact that its compatibility is assumed in kind: kubernetes-sigs/kind#3828)
There was a problem hiding this comment.
How was this expected to work? I don't assume ctr remains 100% compatible but it's not clear how you would use --all-platforms (Is the expectation that you would have to opt out of the transfer API to use --all-platforms?)
There was a problem hiding this comment.
All platforms for unpack has to be resolved in this case on the transfer side and I think we are missing an ability to express the intent to "unpack all platforms whatever those platforms may be" (which maybe we don't actually want anyway).
It's pretty hard to get the permutation of options working as expected and especially for cases we may not explicitly want to support, thats one of the reason we don't guarantee anything in ctr because we want that expressiveness without any promises it will always work.
I think just having it keep the original --local behavior is fine, we should still consider the expressiveness in the API but I doubt unpack everything is often what a caller wants.
|
/cherry-pick release/2.0 |
|
@AkihiroSuda: new pull request created: #11236 In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Fix #11228
ctr images import --all-platformsw/o--localwas failing due tounable to initialize unpacker: no unpack platforms definederror.W/
--local, it unpacks the layers for the strict-default platform.Now
ctr images import --all-platformsw/o--localunpacks the layers for the non-strict default platform.This behavior still differs from
--local.i.e., on an arm64 host, arm/v{5,6,7} layers are unpacked too.