DevHeads.net

Orphaning moby-engine (Docker)

I have orphaned moby-engine, the community Docker package in Fedora,
due to no longer working in a role where I can maintain it as part of
the job. If anyone wants to take it, it is up to date in F30 and
rawhide branches (F29 was not updated for compatibility since it
doesn't enable SELinux), but there is an open issue that should be
addressed before pushing new updates: Docker 18.09 and later
conflicts with runc and containerd since it dropped "docker-" prefixes
from its binaries. I can describe some options and backstory if
needed, but I suppose you could address it however you want as the new
maintainer.

Thanks.

David

Comments

Re: Orphaning moby-engine (Docker)

By Olivier Lemasle at 07/11/2019 - 16:32

On Wednesday, 3 July 2019 19:56:47 CEST David Michael wrote:
I'm open to maintaining this package. However, what was the reason
"moby-engine" packaged its own version of runc and containerd, both
packaged on their own in Fedora?

Re: Orphaning moby-engine (Docker)

By David Michael at 07/11/2019 - 19:57

On Thu, Jul 11, 2019 at 5:22 PM Olivier Lemasle <o. ... at gmail dot com> wrote:
Each upstream Docker release targets a specific commit of each
component (containerd, proxy, runc, and tini) specified at:

<a href="https://github.com/docker/docker-ce/tree/v18.09.7/components/engine/hack/dockerfile/install" title="https://github.com/docker/docker-ce/tree/v18.09.7/components/engine/hack/dockerfile/install">https://github.com/docker/docker-ce/tree/v18.09.7/components/engine/hack...</a>

These specific commits are basically considered part of the release;
e.g. they are included in the Docker versions' release notes. I'm not
aware of the initial decision to bundle the components in the Fedora
package since it was done that way from the beginning before I was a
maintainer (I'd assume it was due to previous Docker versions using
forks of the containerd and runc repos), but from experience
maintaining it for another distro, upstream would send user bug
reports back to you as the distro maintainer if there is any deviation
from what they're shipping. It might end up being less maintenance
work by not unbundling the specified versions.

Also, when I started maintaining it for Fedora, it was explained to me
that moby-engine should follow upstream to provide an expected Docker
experience on Fedora CoreOS (since any specialized container needs
would be implemented in podman), but I don't think it is a priority
for that team anymore. You can probably do whatever you think is best
at this point.

Thanks.

David

Re: Orphaning moby-engine (Docker)

By Daniel J Walsh at 07/13/2019 - 06:49

On 7/11/19 7:57 PM, David Michael wrote:
The problem is that the distribution is distributing a newer version of
runc then the moby-engine currently allows, and podman and Buildah take
advantage of newer features in the runc, therefore moby should not be
shipping its own /usr/bin/runc.  Since this blockes moby and podman
being installed at the same time. (Docker-ce does this as well, and is
wrong to do it.)

If Moby needs an older version of runc then is shipped by the
distribution then it should ship it's version under /usr/libexec

BTW I don't believe the Moby should exactly match Docker-ce, it should
follow the rules of fedora and hopefully be able to work with the other
packages of the distributions like runc/container-selinux etc.

Re: Orphaning moby-engine (Docker)

By Olivier Lemasle at 07/15/2019 - 10:46

Thank you for your answers.

I adopted "moby-engine" and did two new releases:

- moby-engine-18.09.7-4 depends on packages "containerd" and "runc"
instead of conflicting and bundling the binaries. It is packaged for
Rawhide and Fedora 30 (in updates-testing: [1]). I did not see any
regression due to the version inconsistence. Feel free to test it and
to give me feedback!
- moby-engine-18.09.7-5 (only packaged for Rawhide currently) moves
"docker-proxy" and "docker-init" to /usr/libexec/docker, because these
executables, currently packaged in moby-engine, should not be on
$PATH.

[1] <a href="https://bodhi.fedoraproject.org/updates/FEDORA-2019-572b06a0f7" title="https://bodhi.fedoraproject.org/updates/FEDORA-2019-572b06a0f7">https://bodhi.fedoraproject.org/updates/FEDORA-2019-572b06a0f7</a>

Re: Orphaning moby-engine (Docker)

By Daniel J Walsh at 07/11/2019 - 16:43

On 7/11/19 4:32 PM, Olivier Lemasle wrote:
They shouldn't, we have an open Bugzilla on that.

Re: Orphaning moby-engine (Docker)

By Vitaly Zaitsev ... at 07/12/2019 - 03:18

Le jeudi 11 juillet 2019 à 16:43 -0400, Daniel Walsh a écrit :
And eclispeo just finished a mass refresh and debundling pass on
Fedora's Go stack (eclispeo has superpowers), the remaining stickers
are all contenairish stuff (k8s…) so it would be nice if people
interested in containers took a look at how to straighten out this
particular hairball.

The underlying devel stack should be in nice shape now (and we all need
to take care to keep it that way)

Re: Orphaning moby-engine (Docker)

By Bob Mauchin at 07/03/2019 - 16:27

On Wednesday, 3 July 2019 19:56:47 CEST David Michael wrote:

Wasn't there a « Container team » taking care of those packages?

Re: Orphaning moby-engine (Docker)

By Daniel J Walsh at 07/08/2019 - 14:18

On 7/3/19 6:50 PM, Stephen John Smoogen wrote:
Correct the Container Engine team is concentrating on Podman, Skopeo,
Buildah and CRI-O, as replacements of Docker.  We originally helped get
Moby Engine into Fedora, but need volunteers for ongoing maintenance.

Re: Orphaning moby-engine (Docker)

By David Michael at 07/03/2019 - 17:56

On Wed, Jul 3, 2019 at 5:15 PM Robert-André Mauchin <zebob. ... at gmail dot com> wrote:
It was only me for about the last year, and still a single maintainer
before that. Maybe you mean the packages named "docker" or
"docker-latest"? They remained on years-old versions and have been
retired in rawhide for legal reasons, so now moby-engine is the only
Docker package in Fedora. I think there is still an internal team
maintaining the old Docker packages for RHEL, but they have not been
involved with this.

Thanks.

David