On 2018-03-19, Fabian Vogt <fvogt@suse.com> wrote:
I was quite disappointed about the state of multi-arch support in the tooling as well. It's practically completely missing, which meant I had to write a custom script for that.
This is because multi-arch is mostly just useful for making life easier, with making one name refer to multiple images (though users don't actually interact with each of those images). Multi-arch outside of distribution isn't super useful IMHO.
Isn't distribution literally the only purpose of OCI images and registries?
Distribution and interoperability between container tools. But multi-arch is only very useful for the Docker-registry style of distribution (rather than other possible ways of accomplishing distribution). Also the OCI doesn't have a distribution specification at the moment (though it is being worked on as we speak).
It basically takes the images from OBS (built by kiwi, using umoci and skopeo), uploads all blobs (layers, config (why is that a blob...)) and the manifest to the registry. It notes down the digest of the image manifests and uploads a manifestlist combining all those images and assigns it the "latest" tag. The version number of the images is written into the mainfestlist (per-arch) as well, which makes lookup quick and easy.
Creation of multi-arch images is something that is on umoci's roadmap. The main hang-up is that nobody has a good idea for what the UX should be (and other multi-arch image builders have the same problem), and that it becomes harder to reason about operating on an image once there is more than one rootfs associated with it. Not to mention that it's not clear whether there is a usecase that isn't handled by the above outlined skopeo UX.
AFAIK OCI images can be multi-arch as well, so umoci should support that in some way at least. For our purpose at least it would be enough to have per-arch OCI images which we can independently push with skopeo.
umoci does support interoperating with multi-arch images (on a best-effort basis as there are some ambiguous cases I don't really want to get into in this thread), but it doesn't support creating new ones because of the UX problem I mentioned. Internally umoci can trivially support modifying, reading, or creating one. The problem is how should the UX look for doing that? Here are examples of some of the thought-experiments I went through when first looking at this problem when OCI added multi-arch: * Should umoci automatically use the architecture/operating-system of the machine it's being run on? Maybe, but even then there might be more than one image that matches just those requirements. And how should they specify they want to act on a different set of architecture/operating-system? * How should a user specify additional requirements (such as annotations)? Maybe by adding filters on annotations. Should those filters be treated the same as architecture/operating-system (which are not annotations)? What if a user wants to filter non-annotations? * Should we have a UX for dealing with ambiguous cases (effectively giving users the option to select which image they actually meant)? What if umoci is not being run interactively? * Are annotations considered to be applied to children of an Index? After I brought this up and a lot of discussion informally, the conclusion was effectively "no" but this is not mentioned in the specification. * There are certain cases where you may have a "multi-arch" image that doesn't use the Index construct explicitly (by having multiple top-level images that have the same refname). umoci treats this the same as those that have an explicit Index, but it's not clear in the specification if this is meant to be how it should be treated. None of the above properties are specified in the specification, and reference resolution is also unspecified (despite discussions before 1.0 saying that we will specify it). Which means that different tools may have different opinions about refname resolution, but they all would still be considered compliant. So from my point of view, "multi-arch" in OCI is effectively not specified enough in order to make a sane UX decision about it. And while I do have some ideas about what the least insane UX for it would look like (and eventually we will have to implement it if people need to use multi-arch images like this), I'm worried that this will result in more confusion for OCI users. -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>