RFC: copy: add --multi-arch=sparse:...

[nalind]

Add a "sparse:..." value for the copy --multi-arch option, where the "..." is a comma-separated list of instance digests, platform specifications, or the literal word "system" to signify the local platform. Along with https://github.com/containers/image/pull/1938, I think this one of the features described at https://github.com/containers/skopeo/issues/1935#issuecomment-1458649836, give or take the presence of "[" and "]" around the list. If it looks about right, I'll see what sorts of tests I can add to the PR.

[mtrmac]

Actually, should the UI be built around the OCI “platform” triplet at all, or should we have OS/arch filters separately? (And what does that mean for Zstd compression? Probably nothing…)

Just to write down an unfinished version of what I’ve been thinking, to make sure this doesn’t block for an extra day.

• If the only thing we must currently support is system, one option might be to do only that, and punt on the rest. Probably not an ideal effort/benefit outcome, but an option.
• Apart from system, it seems to me that the primary feature is an arch (or arch+variant?) filter for images targeting a single OS. Having the user explicitly write down the OS works but is not the most convenient.
• Looking at the added syntax to also support a digest list within --multi-arch=sparse, maybe we can imagine another level of indirection: --multi-arch=sparse:digest=…, --multi-arch=sparse:platform=$triples, --multi-arch=sparse:arch=$arch_with_optional_variant…. Or maybe --multi-arch=sparse:$arch_with_optional_variant, and --multi-arch=sparse-platform:$triplets, and --multi-arch=sparse:digest=.... With some view on whether we would support a combination of these, and how (to possibly carve out some syntax).
• We absolutely don’t need all of that implemented now. Just system and some, one, way to choose architectures, is probably the 80% solution, without supporting architectures and digests at the same time. So a restrictive option with a restrictive parser is perfectly fine, as long as we don’t box ourselves completely in.

So maybe something in the direction of recognizing --multi-arch=sparse:system, and --multi-arch=sparse:arch=[amd64,s390,arm/v7] would work here? The [] would allow us to unambiguously say arch=[…],digest=[…], OTOH writing that manually would be a pain; quite possibly that might not be worth worrying about.

[nalind]

Took a swing at that sparse syntax. it's not super-pretty, but I tried to reduce the opportunity for copy-paste errors.

[github-actions[bot]]

A friendly reminder that this PR had no activity for 30 days.

[mgs255]

@nalind @mtrmac Is there any chance of this being picked up again? This feature would certainly be very useful for our use case, where we are only interested in two platforms linux/amd64 and linux/arm64. Any interface which would allow copying only those two platforms, re-writing the manifest if required would be a fantastic addition. To me personally, the proposal of --multi-arch=sparse:platform=linux/amd64,linux/arm64 seems pretty clear and understandable.

Not sure that it has been mentioned already, but there would be an open question as to the behaviour if the source only supported a sub-set of the specified sparse filters. Here, it would probably make sense to warn on each of the unmatched filters, but error if there were none that matched.

[snail2sky]

This RFC is really great, but unfortunately the author has forgotten it, so I decided to fork it to solve my problem. Thanks @nalind @mtrmac for the great analysis

[nalind]

I should at least clean up the containers/image part.

[snail2sky]

I should at least clean up the containers/image part.

I think your RFC is very good, but the maintainers of skopeo think that they haven't thought about how to make it more elegant, so this function has never been online. In fact, there is no need to think so much, and this is not a function from zero to one. Docker manifest supports this function, but it is difficult to use. Referring to the docker manifest, the usage of docker pull --platfrom is actually sufficient.