Hi @giuseppe. Thanks for your PR.

I'm waiting for a containerd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Build succeeded.

• containerd-build-arm64 : SUCCESS in 5m 55s (non-voting)

does this depend on it being in an image spec release, to not be out of spec? opencontainers/image-spec#803

does this depend on it being in an image spec release, to not be out of spec? opencontainers/image-spec#803

not sure it should block on a new release of the image specs and if there is any value in it (we should probably try to get a new tag, last release was 3 years ago 😞). It won't affect existing images and how they are handled. The only difference will be that a zstd layer will be decompressed instead of returning an error.

The main reason for such PR is that I am experimenting with zstd (containers/image#1084) and I'd like to not break interoperability with Moby/containerd.

Adding this to the 1.5 milestone, I think adding default support for zstd makes sense without having to rely on configuring a stream processor.

I do have one question on this change though, where was application/vnd.docker.image.rootfs.diff.tar.zstd introduced as a valid/known media type? I couldn't find this referenced in any docker/moby code. What is the scenario where this is necessary over just using the OCI type?

+1 on not waiting for an image-spec since this is only relying on a common sense addition of +zstd

+1 to support zstd without stream-processor

I do have one question on this change though, where was application/vnd.docker.image.rootfs.diff.tar.zstd introduced as a valid/known media type? I couldn't find this referenced in any docker/moby code. What is the scenario where this is necessary over just using the OCI type?

I've added it only for completeness as it is was done for gzip. I agree it is not needed now, if we'll need it in future then we can add.

Pushed a new version without the application/vnd.docker.image.rootfs.diff.tar.zstd change.

Build succeeded.

• containerd-build-arm64 : SUCCESS in 5m 52s (non-voting)

Build succeeded.

• containerd-build-arm64 : SUCCESS in 17m 02s (non-voting)