Multi-arch support?

[erikschul]

Would it be possible to uuse umoci for multi-arch images?

I can use skopeo to download a specific arch/os, for both arm64 and amd64, unpack both, modify both, repack both... but then I can't merge them back.

Would it make sense to for umoci to have:

• a merge command that combines tags
• --arch --os filters for unpack from a multiarch manifest, and repack when building a new manifest.

[cyphar]

Yeah this is something I've wanted to figure out a nice way of supporting for a while (as well as providing more generic modification capabilities for descriptors), but I couldn't figure out a nice UX for it.

[erikschul]

@cyphar Do you mean the design of the CLI commands? Perhaps you could write your ideas and people can suggest improvements.

You could also list use cases.

For me, it's:

• download multi-arch image with skopeo (so compatibility, and an e2e test would be nice, especially supporting older versions since debian stable is behind -- https://repology.org/project/skopeo/packages )
• extract from specific OS/arch
• repack into specific OS/arch for a tag (either updating, or creating a new manifest)
• some base images have many arch/os, so if you're only repacking for some arch/os, the others should be removed (i.e. by creating a new manifest rather than updating)
• skopeo may be used to download a specific arch/os, so repack should allow extracting from different base images and repacking into a single image.

[cyphar]

Some of the UX issues are described in #366 (and #511) and #298. The core issues are:

1. For read operations it's not too bad -- Platform can technically be applied to any descriptor so you would need to apply the filter for all descriptors in the descriptor path as well as possibly selecting the layers based on the filters. This can get ugly quite quickly but it is at least somewhat obvious what the explicit UX should be.
   • The immediate follow-up problem is what the implicit behaviour should be. I guess we should apply filters for the running system if more than one image matches without filters?
2. For bulk operations (umoci rm) we can just apply the operation to all images that match (though we probably should ask the user before doing it if more than one image is matched).
3. For write operations, we need to figure out a few things:
   • What should the procedure be for creating a new multi-arch image?
   • Should we use the recursive index approach or have everything be in index.json? There are upsides and downsides to both, and should we rewrite images to be in our preferred style? There are some spec questions about how matching with recursive indices. This is related to the merging question.
   • When writing, how do we specify the platforms (or annotations) from a UX perspective? RFE: layer/descriptor annotations #298 is the more general problem of what UX should we have when you can specify annotations on any descriptor at any point in the image. Should we also provide a way to change the structure of the image? Honestly I think that something like the git rebase -i interface is the only way to get this to work completely...