+1

+1

Procedural -1 as the discussion in the Containers SIG is ongoing and suggests that this change might result in our producing base images that cannot be used by Docker versions from earlier than 2023. (OCI supported it since 2020).

Also, there's some concern that this would make our base images unsuitable for bootc, which doesn't yet support zstd:chunked.

I'd rather we ask @dwalsh and @walters to join the 2024-07-30 meeting to discuss this with us.

Change is rejected due to insufficient support for the feature among other distributions of container engines. (+6, 1, -0)

I thought the images were going to be created with both gzip and zstd:chunked format? That way Docker versions older then March 2023 would be able to continue to use the gzip format. And podman, buildah, cri-o could use the updated versions.

If we are going to reject this for 2 year old versions of Docker, when do we make the change?

I thought the images were going to be created with both gzip and zstd:chunked format? That way Docker versions older then March 2023 would be able to continue to use the gzip format. And podman, buildah, cri-o could use the updated versions.

Information provided in the meeting stated that we couldn't actually produce an image with both formats. Or do you mean we'd produce (and host) two different copies?

If we are going to reject this for 2 year old versions of Docker, when do we make the change?

Our concern is that if users of other distributions cannot load our images, that's unacceptable. From my perspective, that could actively hamper developers' efforts to support Fedora in addition to their primary distribution.

I thought the images were going to be created with both gzip and zstd:chunked format? That way Docker versions older then March 2023 would be able to continue to use the gzip format. And podman, buildah, cri-o could use the updated versions.

Information provided in the meeting stated that we couldn't actually produce an image with both formats. Or do you mean we'd produce (and host) two different copies?

we can produce images that are in both formats, so that old clients can use gzip; while newer ones (where "newer ones" means anything except Docker versions older than March 2023) can take advantage of zstd.

how would that work exactly? do you mean we can create two versions of each container image we produce, zstd and gzip, and push both out to registries? which would you get with a podman pull fedora:41 or a FROM fedora line in a Containerfile? or do you mean something else?

found the answer myself, I think - it's tricks with manifests.

still, that means we need to implement producing this manifest. and how does that interact with the multi-arch manifest? do we need a manifest with dimensions for both arch and compression type? or do they kind of nest, so we have a manifest for each "individual" image with both zstd and gzip options, and the multi-arch manifest just references those manifests?

They basically sit next to each other. No change of the manifest. The way older Docker works, is it will pull the first image that matches, and if setup correctly it will be the gzip one. Podman is smart enough to look for the zstd one and then fall back to the gzip one.

Docker itself is starting the conversation about moving to zstd.

https://github.com/docker-library/official-images/issues/17720

They have setup a pretty could chart showing which versions of Container engines can handle zstd and which can not, and where they are in their lifecycle.