On 6/11/19 9:25 AM, Dmitry Smirnov wrote:
> On Monday, 10 June 2019 3:03:23 PM AEST Arnaud Rebillout wrote:
>> I also want to try to unbundle
>> containerd from the docker package,
> This may be very risky to do so one have to have a good justification what 
> those risks are taken for.
>
> It has been attempted in the past with disastrous results. Containerd is used 
> by Docker (exclusively?) and with very specific vendoring. With current 
> upstream culture of incompetence in regards to versioning, another attempt to 
> ship containerd separately is likely to fail. Unbundling containerd should be 
> considered very very carefully with full understanding of why burning effort 
> for the attempt.
>
AFAIU there's two issues:

1. the fact that docker uses snaphots of containerd.

2. the fact that both docker and containerd vendor each other, leading
to unbreakable circular dependencies.

For issue 1, I would have a the docker releases accross the last year,
and see what version of containerd they use. If it happens that they
consistently use releases of containerd rather than snapshots, then
maybe we can consider that issue 1 is gone (but it's true that they're
no warranty that they won't go back to using snapshots later down the
road....)

For issue 2, I would try to have a look at what they vendor from docker,
once again over a one year time span, and try to assess it they're doing
any progress un-bundling docker parts from containerd, or not. I've seen
in Shengjing Zhu's containerd package that there is still some vendoring
of docker parts, so I don't think it's solved yet, but maybe it's on the
way.

Even if these two points are solved, it's true that there's a risk that
it comes back, even more both projects have more or less the same
upstream. I'm not really aware of who develop what, and if both projects
are really developed separately, or by the same group of people.

Reply via email to