You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe what should be investigated or refactored
Crane has been an instrumental library to Zarf. It is responsible one of the most core features of our product, pulling and pushing images. However, we've had several issues while using crane. In particular, not accepting context, concurrent pulls and caching of non container OCI images tend to cause trouble. See:
We should consider alternatives to fix these issues, and open ourselves up to further improvements.
ORAS (OCI registry as storage) is a project that has become popular in the past few years or so. It is a go library for interacting with OCI registries. We use ORAS already to publish and pull Zarf packages.
https://github.com/containers/image - this is the library that skopeo uses for image pulls. I have not looked deeply into the code, but it is worth looking at how another successful tool with a similar mission does pulls and pushes
Additional context
Moving off Crane will present challenges. Crane also supports the oci-dir format, which syft uses to scan images local, this is how SBOMs are created during zarf package create. The Crane CLI is embedded directly into Zarf, removing it entirely will no doubt cause a breaking change in the workflow of some users. The Crane CLI has functionality to pull images from the local Docker daemon which would need replacement as well
The text was updated successfully, but these errors were encountered:
Both ORAS and https://github.com/containers/image seem to be reasonable alternatives to Crane. Both accept context, and seem to have more active contributions and updates. Both seem to be faster than crane, more official benchmarks to come. ORAS supports the same OCI format that Crane and Syft use, while "image" seemingly does not. "image" supports pulling from the docker daemon while ORAS does not.
ORAS does allow embedding itself into other CLIs with Cobra easily. I am not sure what our appetite for breaking changes are, but it seems to me that it might make sense to deprecate zarf tools Crane and replace it with zarf tools oras. Crane and ORAS share much of the same functionality.
Further testing is needed, but neither seem to natively support pulling multiple images concurrently. Layers can be pulled concurrently, but there is no hook in either library to pull images concurrently. Further testing is required. I have a feeling that I may end up with the same Crane errors of making multiple calls to the same file.
Both seem to have a cache, but further testing on these caches is required
Describe what should be investigated or refactored
Crane has been an instrumental library to Zarf. It is responsible one of the most core features of our product, pulling and pushing images. However, we've had several issues while using crane. In particular, not accepting context, concurrent pulls and caching of non container OCI images tend to cause trouble. See:
Alternatives
We should consider alternatives to fix these issues, and open ourselves up to further improvements.
Additional context
Moving off Crane will present challenges. Crane also supports the oci-dir format, which syft uses to scan images local, this is how SBOMs are created during
zarf package create
. The Crane CLI is embedded directly into Zarf, removing it entirely will no doubt cause a breaking change in the workflow of some users. The Crane CLI has functionality to pull images from the local Docker daemon which would need replacement as wellThe text was updated successfully, but these errors were encountered: