feature: Support list of archs for sync command

[cwseger]

History:

• I have been using skopeo sync to specifically copy linux/amd64 images.
  • skopeo sync --override-os linux --override-arch amd64 ...

Issue:

• Sometimes amd64 containers don't run on arm based Macs.
• To fix this I need to expand the image archs I'm copying to include arm64 images.

Current Solution:

• From what I can tell there isn't a way to specify more than a single arch in the --override-arch option so I am copying over all the archs for the image.
  • skopeo sync --override-os linux --all ...
• This is less than ideal since I only care about 2 image archs but am copying/storing many more than needed.

Proposed Solution:

• It would be helpful to somehow specify a list of archs to copy over whether it be a modification to the --override-arch option or an entirely new option.
  • Re-use existing option: skopeo sync --override-os linux --override-arch amd64 arm64 ...
  • Create new option: skopeo sync --override-os linux --archs amd64 arm64 ...

Notes:

• Thanks for your time and effort on skopeo!

[mtrmac]

Thanks for your report.

Yeah, that’s not currently possible and it’s a reasonable RFE.

skopeo copy has a --multi-arch option, and it’s anticipated that that could also allow choosing a subset of architectures (but that doesn’t actually exist today). It would, then, be natural to expose that for skopeo sync as well.

(Note that any such architecture subset option faces the trade-off between dropping the other architectures from the multi-arch manifest list, breaking digest references, and using the original manifest list without copying some architectures, with dangling references, which is rejected by some registries.)

[github-actions]

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

[anthonyhaussman]

I'll be interested in the same feature 🙏 ❤️

[github-actions]

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

[bertbaron]

We also would like this feature for the same reason as @cwseger. Syncing all architectures will be simply too much for us. I might be able to create a PR for this if it's not too involved, but I would need some guidence.

skopeo copy has a --multi-arch option, and it’s anticipated that that could also allow choosing a subset of architectures (but that doesn’t actually exist today). It would, then, be natural to expose that for skopeo sync as well.

Do you have a suggestion on how the option(s) should look like for copy as well as for sync?

(Note that any such architecture subset option faces the trade-off between dropping the other architectures from the multi-arch manifest list, breaking digest references, and using the original manifest list without copying some architectures, with dangling references, which is rejected by some registries.)

What would be the effect of the first option? It looks like the cleaner option but I guess I don't understand the consequences.

Any hints on where code changes should probably applied are welcome of course.

[mtrmac]

Do you have a suggestion on how the option(s) should look like for copy as well as for sync?

Some syntax that clearly won’t conflict with other current/future values, and perhaps allows future evolution.

Maybe --multi-arch arch=arch1,arch2,…? That would still allow some future --multi-arch platform=(arch,OS,variant),(arch,OS,variant) or the like.

Plus, possibly, an option to differentiate between the sparse copies / manifest-editing copies discussed below, if you need the manifest-editing variant.

---

Note that any such architecture subset option faces the trade-off between dropping the other architectures from the multi-arch manifest list, breaking digest references, and using the original manifest list without copying some architectures, with dangling references, which is rejected by some registries.)

What would be the effect of the first option? It looks like the cleaner option but I guess I don't understand the consequences.

Given an original image with digest sha256:originalDigest, which points at individual images for (amd64, arm64, 386, s390x) and all of these individual images exist:

• The first alternative creates a “stripped” image which points at individual images for e.g. (amd64, arm64) only, and both exist. This means the top-level manifest list / OCI index changes, and has some other digest than originalDigest.
• The second alternative creates a “sparse” image where the top-level manifest list / OCI index stays the same, with digest sha256:_originalDigest (i.e. digest references keep working). Because it is the same, it still points at individual images for points at individual images for (amd64, arm64, 386, s390x) — it’s just that they don’t actually exist on the destination, the destination only contains the desired (amd64, amd64) variants. An extreme variant of this is the current --multi-arch=index-only, which creates a sparse image without copying any of the individual ones.

---

Any hints on where code changes should probably applied are welcome of course.

The actual implementation in https://github.com/containers/image/ , as some new field as an alternative to c/image/copy.Options.ImageListSelection. The “sparse” approach would be fairly easy to do right there, the “stripped” option would require a bit more work to implement the editing feature, probably as an internal-only API.

Within Skopeo, that would be just a CLI option parser that fills the copy.Options fields, probably shared between copy and sync in utils.go .

[bertbaron]

Thanks for the response. I tested copy with index-only against ECR but unfortunately this doesn't seem to be supported, it complains about the images being unkown. So I guess the first option seems to be the only option for us then.

[github-actions]

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

[github-actions]

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

[github-actions]

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

[druchoo]

/fresh 🙏

[rhatdan]

If an issue becomes old and not being worked on, it basically means that some from the community needs to step up and try to implement it. The core developers either do not have the time or deem other features more important to implement.

[github-actions]

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

[github-actions]

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

[druchoo]

/fresh

[github-actions]

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