Hi, Am Montag, 19. März 2018, 16:32:17 CET schrieb Aleksa Sarai:
On 2018-03-19, Fabian Vogt <fvogt@suse.com> wrote:
opensuse/amd64:42.3 (or opensuse/amd64:leap) is what we would've suggested using earlier, but with this new setup I would hope that means we're going to push everything to opensuse/<flavor>:<version>.
My original plan was to have a single source for official images. Leap will be available only as part of the official library (so opensuse:15.0) whereas Tumbleweed only as opensuse/tumbleweed.
For Leap there's IMO no reason to move it from the official images, except the convoluted submission process, sending a pull request with a text file containing git repos and hashes...
The issue is actually larger than this. The official-library doesn't use the image we create in OBS directly. Rather it takes a tar of the rootfs and then applies them *inside* a Docker build.
Yes, that's part of the "convoluted submission process"...
Because they (still!) use AUFS, this causes the rootfs to not be identical to the one we built (in particular this strips certain xattrs like "security.capability").
Ouch, I did not know that. Does https://github.com/docker-library/official-images/blob/master/library/opensu... ("Constraints: !aufs") not have an effect? I assume it would apply not only to the users but also to the builder itself. If it doesn't, it's actually a reason to pull all of the images from the library and not just tumbleweed.
We discovered this when the official-library build broke when we fixed "security.capability" support in KIWI (they didn't notice the breakage during the PR process because they test PRs on non-AUFS Docker, but build it on AUFS Docker), and I had to write some Docker patches to "fix" it so that our images would be in official-library again (the build had been failing since).
I would always recommend that people use the images we build in OBS, for the same reason we recommend people use packages built in OBS rather than packages built manually via rpmbuild(1) on a random machine in some stranger's basement.
We'll likely have an openSUSE registry and notary, which means this won't be an issue in the long term anymore. I'll have to read up on the notary subject though. I don't think it's an issue for the opensuse/ NS on docker hub either, as there we control every bit of the blobs landing on the client and they can verify that by comparing the digest. We'll just have to make the list easy to access and provide a guide for verification. It's basically identical to the downloading of .iso images from download.opensuse.org - the download itself and the file can be modified, but we provide a checksum for (sadly voluntary) verification. There's a few comments about that in the osc-plugin-factory PR.
The obvious downside with only having "opensuse/..." images is that people won't know why "docker pull opensuse" doesn't work anymore.
Yes, but that just needs to be communicated. Who knows, if done properly it might serve as motivation for the official library to get some restructuring. 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