On 1/7/20 1:29 AM, Shengjing Zhu wrote:
We should keep containerd version in sync with docker. eg docker
19.03.x with containerd 1.2.x. And I guest next docker major version
will use containerd 1.3.x.
Agreed on that, as long as both projects are in sync upstream, that can
work.
Talking about versions, looking at the file
https://download.docker.com/linux/debian/dists/buster/stable/binary-amd64/Packages,
I can see that:
- the docker-ce package started to depend on container.io from the 18.09.x
series (it's been a while: good)
- the latest version of docker-ce "5:19.03.5~3-0~debian-buster" depends on
containerd.io (>= 1.2.2-3)... Where is the source for this package? Is containerd.io
patched here?
I found a comment from someone asking for the sources of the package:
https://github.com/containerd/containerd/issues/1508#issuecomment-461413010.
The comment went unanswered. A bit more research, and still no idea where are
the source for this package. Do you have an idea?
Neither do I :(
But let's be optimized about this. There's no reason for docker
upstream to _hide_ some patches which are not applied in containerd
upstream :)
Actually if you look at commits in containerd release branch, the
people from docker are actively backporting things.
I don't think anyone hides anything, but I don't want to be in the
situation were:
- you install docker and containerd from docker repos, everything works
- you install docker and containerd from debian repos (same versions as
in docker repos), and some things don't work...
Why? Because there are some patches in containerd.io (from docker repos)
that we are not aware of...
That's one thing I'm worried about as long as I don't have the source
package for containerd.io.
The second thing is that, in any case, we shouldn't patch containerd to
accomodate docker. If docker is the consumer of containerd, and can't
work with it "as is", then docker has to be patched, not containerd.
All of that is theoretical speaking, maybe in the end docker and
containerd can work with each other, from tagged version, and without
any patch.
But this has never been the case up to now (I mean, docker could never
/build/ against a tagged version of containerd, at least), so I have
reasons to be cautious, and not over optimistic.
CRI makes containerd useful without docker in a kubernetes worker
node. (That's why I want a separate containerd package)
I have some mistakes in my previous sentence. It should be,
+ github.com/containerd/cri pull in github.com/docker/docker.
+ github.com/containerd/containerd/cmd/containerd pull in
github.com/containerd/cri
So only when you build containerd binary(with cri), you will need
github.com/docker/docker.
No consumer will pull in github.com/containerd/containerd/cmd/..., so
no need to pull in github.com/docker/docker.
There's no circular dependencies, apparently.
Thanks for the details.
Correct me if I'm wrong, but there's still a bit of a circular dep, in
the sense that the Build-Depends are for the source package, not for
each binary package produced.
So, assuming that we want to bump both docker and containerd to a new
major version, the situation could very well be:
1) try to update containerd -> oh, requires a new version of containerd/cri
2) so let's try to update containerd/cri -> oh, requires a new version
of docker
3) so let's try to update docker -> oh, requires a new version of containerd
4) back to 1...
That wouldn't be the first circular of this kind, we already had it at
some point with fsouza-go-dockerclient, even though I think these days
it's gone.
Anyway.
I think you can already upload containerd to unstable at this point? Or
is there some blocker?
I'm not fundamentally against attempts to un-bundle containerd from
docker, but the reality is that I don't know when (if ever) I can spend
time giving it a try, and in the meantime you shouldn't be waiting on
me. The docker package shouldn't block the containerd package from being
in unstable, and unless I'm mistaken, at the moment it doesn't.
In the short-term, for unstable, I would be in favor of having
containerd, and also docker.io as it is now, ie. with bundled
containerd. And in a longer term, possibly before bullseyes, if it seems
realistic, I will find some time to work on un-bundling.
Having someone working on the containerd packaging is already a great
improvement, so it's good that this discussion is taking place.
Thanks!
Arnaud
