Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

manifest,zstd: give priority to zstd compressed images when pulling image from a manifest list #1789

Merged
merged 3 commits into from
Feb 28, 2023

Conversation

flouthoc
Copy link
Contributor

@flouthoc flouthoc commented Jan 12, 2023

While perform a pull from manifest list of type application/vnd.oci.image.index.v1+json make sure that if more than one image exists for the same platform then give priority to the one compressed with zstd.

Annotation io.github.containers.compression.zstd is expected to be set for the image compressed with zstd.

For users who wish to test this feature with buildah/podman

# create manifest list
buildah manifest create host/repo:latest
# create image 
buildah build -t test1 .
# create another image
buildah build -t test2 .

# add test1 to manifest list
buildah manifest add host/repo:latest sha:<test1>
# add test2 to manifest list
buildah manifest add host/repo:latest sha:<test2>

# tag zstd compressed image
buildah manifest annotate --annotation io.github.containers.compression.zstd=true host/repo:latest sha256:<test1>
# push to the repo
buildah manifest push --all host/repo:latest docker://host/repo:latest

# Fresh system !!! Pull from manifest list should give priority to zstd compressed image
buildah pull host/repo:latest

@flouthoc flouthoc marked this pull request as draft January 12, 2023 11:31
@flouthoc flouthoc marked this pull request as ready for review January 12, 2023 11:40
Copy link
Member

@giuseppe giuseppe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

manifest/oci_index.go Outdated Show resolved Hide resolved
internal/image/fixtures/schemazstdselection.json Outdated Show resolved Hide resolved
manifest/oci_index.go Outdated Show resolved Hide resolved
manifest/oci_index.go Outdated Show resolved Hide resolved
manifest/oci_index.go Outdated Show resolved Hide resolved
manifest/oci_index.go Outdated Show resolved Hide resolved
@mtrmac
Copy link
Collaborator

mtrmac commented Jan 12, 2023

Fresh system !!! Pull from manifest list should give priority to zstd compressed image

I’d expect skopeo copy [--multi-arch=system] docker://… docker://… to expose this logic without needing to wipe c/storage.

@flouthoc flouthoc force-pushed the list-zst branch 4 times, most recently from 2284e25 to 765fc08 Compare January 13, 2023 06:52
manifest/oci_index.go Outdated Show resolved Hide resolved
manifest/oci_index.go Outdated Show resolved Hide resolved
@flouthoc flouthoc force-pushed the list-zst branch 3 times, most recently from 42b2cf4 to 25f81e7 Compare January 13, 2023 08:54
@flouthoc
Copy link
Contributor Author

flouthoc commented Jan 13, 2023

@vrothberg @mtrmac PTAL again as discussed before I have made it configurable option and later on it can be relayed to SystemContext via copyOptions.

@flouthoc flouthoc requested review from vrothberg and mtrmac and removed request for vrothberg January 13, 2023 08:59
@TomSweeneyRedHat
Copy link
Member

@flouthoc, I think you need a rebase.

@mtrmac
Copy link
Collaborator

mtrmac commented Jan 13, 2023

I’m afraid I’ll only return to this carefully next week.

Just to give a brief (aesthetic ?) preference: Eventually most of the compression conversion options (add a variant, drop a variant, ensure a variant exists) are going to exist in copy.Options, and make no sense outside of copy.Options. So I’m not too enthusiastic about adding an option to types.SystemContext now — we would keep it forever mostly just as an artifact of the order in which we develop things; that seems entirely avoidable. Or are we in some rush to deliver this immediately? (OTOH, admittedly, adding an option next to things like ArchitectureChoice would be fairly clean.)

So I’d prefer starting with making manifest.List private, and an option in copy.Options, not SystemContext. (In general, SystemContext is a bit of a mistake.)


But I also desire an option in a configuration file. I think that registries.conf can be a nice host for that.

But wouldn’t such an option be necessary also for the two OCI transports? That wouldn’t work with registries.conf. Especially if the thinking is that this should be a fail-safe that is disabled by default, that option seems like something that shouldn’t be transport-specific.

It might well make sense to add a registries.conf, per-scope, override mechanism, but that seems to me to be a more advanced feature, not essential for the very first version. (It would also require passing that choice through private.ImageDestination, because registries.conf is docker://-specific.)

@flouthoc
Copy link
Contributor Author

@mtrmac adding it to copy.Options and passing it to manifest.List SGTM. Just a small doubt since we had a discussion on the before and there was a preference to do both of these in a different PR. Should I create a new PR for it or are you fine in this PR itself ?

Or are we in some rush to deliver this immediately?

I don't think there is a rush, I think getting this feature in the right way would be better :)

@mtrmac
Copy link
Collaborator

mtrmac commented Jan 13, 2023

I’d prefer a separate PR to introduce (probably) internal/manifest.List as an extension / replacement (not 100% sure which one, preferably an extension if possible) for the stable public manifest.List; with no new added functionality.

Then this PR can add/change the internal ChooseInstance (which no longer has public API restrictions) to add a compression option, and use that from copy.

@vrothberg
Copy link
Member

Extending copy.Options SGTM. That will make the behavior opt-in and address my fear.

But wouldn’t such an option be necessary also for the two OCI transports? That wouldn’t work with registries.conf.

That's a fair point. containers.conf may be better-suited for that BUT neither skopeo nor CRI-O are using it yet.

types/types.go Outdated Show resolved Hide resolved
@flouthoc
Copy link
Contributor Author

@mtrmac PR for flipping dependency and introducing internal.manifest.List #1791 PTAL

@mtrmac mtrmac added the kind/feature A request for, or a PR adding, new functionality label Feb 3, 2023
manifest/oci_index.go Outdated Show resolved Hide resolved
manifest/list_test.go Outdated Show resolved Hide resolved
manifest/oci_index.go Outdated Show resolved Hide resolved
types/types.go Outdated Show resolved Hide resolved
types/types.go Outdated Show resolved Hide resolved
Copy link
Collaborator

@mtrmac mtrmac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One last line I think

internal/manifest/oci_index.go Outdated Show resolved Hide resolved
@flouthoc flouthoc force-pushed the list-zst branch 3 times, most recently from 1af410c to 05ea212 Compare February 27, 2023 18:36
Copy link
Collaborator

@mtrmac mtrmac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, assuming tests pass.

Thanks!

While perform a pull from manifest list of type
`application/vnd.oci.image.index.v1+json` make sure that if more
than one image exists for the same platform then give priority to the
one compressed with `zstd`.

Annotation `io.github.containers.compression.zstd` is expected to be set
for the image compressed with `zstd`.

Signed-off-by: Aditya R <arajan@redhat.com>
Instrument copy.Image to use ChooseInstanceByCompression so pulling of
zstd images can be given priority.

Signed-off-by: Aditya R <arajan@redhat.com>
* When d.platform == nil there is no need to iterate
`len(manifests)*len(wantedPlatforms)` times and move processing for case
`d.platform == nil` outside of the wanted platform loop

* Retrofit tests to verify use-cases when platform is nil.

Signed-off-by: Aditya R <arajan@redhat.com>
@flouthoc
Copy link
Contributor Author

Copy link
Member

@vrothberg vrothberg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, nice work!

@vrothberg vrothberg merged commit d18058b into containers:main Feb 28, 2023
mtrmac added a commit to mtrmac/image that referenced this pull request Jul 15, 2023
Setting SystemContext.ArchitectureChoice to "" does not mean "match any/the first platform";
it's the default behavior of SystemContext, and it means "choose for the current runtime
architecture". (Originally discussed in
containers#1789 (comment) )

I.e. on amd64 these two test cases are redundant with the first two instances above,
and on other achitectures (notably ARM) they cause failures.

So just drop them.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>
mtrmac added a commit to mtrmac/image that referenced this pull request Jul 15, 2023
Setting SystemContext.ArchitectureChoice to "" does not mean "match any/the first platform";
it's the default behavior of SystemContext, and it means "choose for the current runtime
architecture". (Originally discussed in
containers#1789 (comment) )

I.e. on amd64 these two test cases are redundant with the first two instances above,
and on other architectures (notably ARM) they cause failures.

So just drop them.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>
flouthoc pushed a commit to flouthoc/image that referenced this pull request Aug 4, 2023
Setting SystemContext.ArchitectureChoice to "" does not mean "match any/the first platform";
it's the default behavior of SystemContext, and it means "choose for the current runtime
architecture". (Originally discussed in
containers#1789 (comment) )

I.e. on amd64 these two test cases are redundant with the first two instances above,
and on other architectures (notably ARM) they cause failures.

So just drop them.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>
mtrmac added a commit to mtrmac/image that referenced this pull request Aug 4, 2023
Setting SystemContext.ArchitectureChoice to "" does not mean "match any/the first platform";
it's the default behavior of SystemContext, and it means "choose for the current runtime
architecture". (Originally discussed in
containers#1789 (comment) )

I.e. on amd64 these two test cases are redundant with the first two instances above,
and on other architectures (notably ARM) they cause failures.

So just drop them.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>
mtrmac added a commit to mtrmac/image that referenced this pull request Aug 5, 2023
Setting SystemContext.ArchitectureChoice to "" does not mean "match any/the first platform";
it's the default behavior of SystemContext, and it means "choose for the current runtime
architecture". (Originally discussed in
containers#1789 (comment) )

I.e. on amd64 these two test cases are redundant with the first two instances above,
and on other architectures (notably ARM) they cause failures.

So just drop them.

Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature A request for, or a PR adding, new functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants