Re: [opensuse-factory] Changes to the openSUSE images on Docker Hub

Hi, Am Montag, 19. März 2018, 16:25:23 CET schrieb Aleksa Sarai:

On 2018-03-19, Fabian Vogt wrote:

...

...

...

- In a week, opensuse/amd64, opensuse/arm64v8, opensuse/s390x and opensuse/ppc64le will be removed. Due to multi-arch images, they are no longer necessary.

How are we consolidating the multi-arch images from the single-arch images built in OBS? umoci doesn't have explicit support for creating multi-arch images (though it can interact with them), and skopeo doesn't really like creating OCI multi-arch images either.

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?

It's my impression that having skopeo be able to push an OCI image to specific Docker entries in the multi-arch manifest would resolve most of these issues -- because then you can just use the single-arch images built locally and then push them all to the same distribution reference.

Yes, that sounds like the best option.

...

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.

If you have any ideas here, I'd appreciate it if you can add it in an issue on https://github.com/openSUSE/umoci.

...

I would expect that even if there were multi-arch compatible tooling, it wouldn't allow the advantages this currently has, especially embedding the version into the manifestlist itself, but also not requiring to download all layers for all archs before uploading.

Not necessarily, but I agree it would probably would be harder to implement to have the same advantages as it would have to touch both umoci and skopeo.

Cheers, Fabian -- Fabian Vogt - Release Engineer SUSE Linux GmbH GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org