Skip to content
This repository has been archived by the owner on Nov 7, 2024. It is now read-only.

Add support for zstd:chunked #608

Closed
cgwalters opened this issue Mar 5, 2024 · 11 comments · Fixed by #615 or #622
Closed

Add support for zstd:chunked #608

cgwalters opened this issue Mar 5, 2024 · 11 comments · Fixed by #615 or #622
Labels
enhancement New feature or request triaged

Comments

@cgwalters
Copy link
Member

Should be a trivial patch

@travier
Copy link
Member

travier commented Mar 27, 2024

From "rpm-ostree":

error: Importing: Unencapsulating base: Unhandled layer type: application/vnd.oci.image.layer.v1.tar+zstd

travier added a commit to travier/ostree-rs-ext that referenced this issue Mar 27, 2024
cgwalters pushed a commit to travier/ostree-rs-ext that referenced this issue Mar 27, 2024
@travier travier reopened this Mar 27, 2024
@travier
Copy link
Member

travier commented Mar 27, 2024

Unfortunately #615 is for zstd only, not zstd:chunked which is not supported by the oci_spec library yet.

@travier
Copy link
Member

travier commented Mar 27, 2024

For reference: containers/storage#775

cgwalters added a commit to cgwalters/ostree-rs-ext that referenced this issue Apr 28, 2024
This would be a workaround for the async_compression bug
in ostreedev#608

- This changes the public API so we need a semver bump
- It's pretty risky anyways and we may be better off with
  spawning a helper thread instead of using async_compression
@jmarrero
Copy link
Member

From "rpm-ostree":

error: Importing: Unencapsulating base: Unhandled layer type: application/vnd.oci.image.layer.v1.tar+zstd

I am seeing this on OCP 4.16 is there a fix that needs to be backported?

@jmarrero
Copy link
Member

jmarrero commented Jun 11, 2024

Also are we building images with application/vnd.oci.image.layer.v1.tar+zstd support? without supporting it yet on OCP or is it the podman version I used for the layered image?.. /me goes try rebuilding the image in RHEL.

@travier
Copy link
Member

travier commented Jun 11, 2024

Looks like podman started pushing using zstd compression by default (?). We only have support for that in the latest rpm-ostree release AFAIK.

@cgwalters
Copy link
Member Author

I am seeing this on OCP 4.16 is there a fix that needs to be backported?

Where? In Prow CI? Local builds? A customer bug?

Looks like podman started pushing using zstd compression by default (?).

Wait, really? That's going to cause some fallout for sure. I think this is probably from https://bodhi.fedoraproject.org/updates/FEDORA-2024-ab42dd0ffb

@cgwalters
Copy link
Member Author

@jmarrero
Copy link
Member

I am seeing this on OCP 4.16 is there a fix that needs to be backported?

Where? In Prow CI? Local builds? A customer bug?

Using the clusterbot created cluster OCP 4.16-rc3 I was trying to help verify an issue that includes replacing the kernel and hit this with coreos layering.

I did build the image I am rebasing to using Fedora 40.

@cgwalters
Copy link
Member Author

OK, in the meantime, the workaround for this is probably to do skopeo copy --dest-compress-format=gzip containers-storage:<local image> docker://quay.io/exampleuser/someuser

Or set compression_format = "gzip" in /etc/containers/containers.conf (locally) or revert the change in the /usr copy in custom images.

@jmarrero
Copy link
Member

Thanks that skopeo command made everything better!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request triaged
Projects
None yet
3 participants