mbox series

[v2,0/9] upgrade docker-engine and associated components

Message ID 20180301072012.25884-1-christian@paral.in
Headers show
Series upgrade docker-engine and associated components | expand

Message

Christian Stewart March 1, 2018, 7:20 a.m. UTC
Hi all,

This series upgrades Docker and associated components:

 - runc to 9f9c96235cc97674e935002fc3d78361b696a69e
 - docker-containerd to v1.0.2
 - docker-engine to v2018.03.0-ce-rc1

Fixes:

 - Btrfs is disabled in containerd if not included in the target system and selected.

Suggested naming changes:

 - docker-containerd -> containerd

This project has been split off from Docker, and is now hosted at:

  https://github.com/containerd/containerd

It is not specifically a docker project.

 - docker-engine -> docker-ce

Docker "Community Edition" is the name for the daemon and CLI bundled
together by the "moby" bundler/project duo.

It's still named the "Engine" but with the CLI as well, it makes more
sense to name it "Docker Community Edition" which also avoids a
collision with the "docker" package.

An old version of this series adding docker-init exists.

 - https://patchwork.ozlabs.org/patch/827886/

Changes v1 -> v2:

 - Make static default for tini and dumb-init
 - Bump package versions (as described above)
 - Added fix to not link against libsystemd without systemd
 - Removed unnecessary stack protector flags from tini
 - Fixed confusing commit messages
 - Upgraded to 18.03.0-rc1, skipping 18.02, to address critical bugs in 2018.02.
 - Tested on Raspberry Pi 3, Odroid XU4, Odroid HC2, and Raspberry Pi 0.

Best,
Christian Stewart

---

Christian Stewart (9):
  tini: new package
  dumb-init: new package
  docker-engine: add support for init processes
  docker-engine: select static for tini and dumb-init
  docker-proxy: new package
  docker-engine: add dependency on docker-proxy
  runc: bump to 9f9c96235cc
  docker-containerd: bump to v1.0.2
  docker-engine: bump to v18.03.0-ce-rc1

 package/Config.in                                |  3 ++
 package/docker-containerd/Config.in              | 12 +++++
 package/docker-containerd/docker-containerd.hash |  2 +-
 package/docker-containerd/docker-containerd.mk   | 38 +++++++++++----
 package/docker-engine/Config.in                  | 29 ++++++++++++
 package/docker-engine/docker-engine.hash         |  2 +-
 package/docker-engine/docker-engine.mk           | 59 ++++++++++++++++--------
 package/docker-proxy/Config.in                   | 18 ++++++++
 package/docker-proxy/docker-proxy.hash           |  2 +
 package/docker-proxy/docker-proxy.mk             | 46 ++++++++++++++++++
 package/dumb-init/Config.in                      |  7 +++
 package/dumb-init/dumb-init.hash                 |  2 +
 package/dumb-init/dumb-init.mk                   | 24 ++++++++++
 package/runc/runc.hash                           |  2 +-
 package/runc/runc.mk                             | 17 ++++---
 package/tini/Config.in                           | 16 +++++++
 package/tini/tini.hash                           |  2 +
 package/tini/tini.mk                             | 35 ++++++++++++++
 18 files changed, 278 insertions(+), 38 deletions(-)
 create mode 100644 package/docker-proxy/Config.in
 create mode 100644 package/docker-proxy/docker-proxy.hash
 create mode 100644 package/docker-proxy/docker-proxy.mk
 create mode 100644 package/dumb-init/Config.in
 create mode 100644 package/dumb-init/dumb-init.hash
 create mode 100644 package/dumb-init/dumb-init.mk
 create mode 100644 package/tini/Config.in
 create mode 100644 package/tini/tini.hash
 create mode 100644 package/tini/tini.mk

Comments

Peter Korsgaard March 1, 2018, 10:15 a.m. UTC | #1
>>>>> "Christian" == Christian Stewart <christian@paral.in> writes:

 > Hi all,
 > This series upgrades Docker and associated components:

 >  - runc to 9f9c96235cc97674e935002fc3d78361b696a69e
 >  - docker-containerd to v1.0.2
 >  - docker-engine to v2018.03.0-ce-rc1

I am far from a docker expert, but isn't this an 'edge' release? Given
the Buildroot release schedule, wouldn't it make more sense to use the
'stable' releases with a similar quarterly support/release schedule?
Christian Stewart March 1, 2018, 5:54 p.m. UTC | #2
Hi Peter,

Peter Korsgaard <peter@korsgaard.com> writes:
>  >  - runc to 9f9c96235cc97674e935002fc3d78361b696a69e
>  >  - docker-containerd to v1.0.2
>  >  - docker-engine to v2018.03.0-ce-rc1

>
> I am far from a docker expert, but isn't this an 'edge' release? Given
> the Buildroot release schedule, wouldn't it make more sense to use the
> 'stable' releases with a similar quarterly support/release schedule?

Yes, it's intended to be merged into "next" for release not in Buildroot
2018.02 but later. I thought I had mentioned that in the cover letter,
but I guess that was in another revision, lost somewhere months ago.

The reason is because from our testing on various devices with varying
container workloads, the only two stable versions (with no critical
bugs) of Docker that we have been able to find were early 2017 or 2018.03-rc1.

2018.03-rc1 will be released as a full release soon as 2018.02 was
completely unusable due to a "container already exists" error when
trying to start a container.

If you would like me to make another series based around 17.12.1-ce that
was just released, I would be happy to do so.

Best,
Christian Stewart
Peter Korsgaard March 1, 2018, 6:15 p.m. UTC | #3
>>>>> "Christian" == Christian Stewart <christian@paral.in> writes:

 > Hi Peter,
 > Peter Korsgaard <peter@korsgaard.com> writes:
 >> >  - runc to 9f9c96235cc97674e935002fc3d78361b696a69e
 >> >  - docker-containerd to v1.0.2
 >> >  - docker-engine to v2018.03.0-ce-rc1

 >> 
 >> I am far from a docker expert, but isn't this an 'edge' release? Given
 >> the Buildroot release schedule, wouldn't it make more sense to use the
 >> 'stable' releases with a similar quarterly support/release schedule?

 > Yes, it's intended to be merged into "next" for release not in Buildroot
 > 2018.02 but later. I thought I had mentioned that in the cover letter,
 > but I guess that was in another revision, lost somewhere months ago.

 > The reason is because from our testing on various devices with varying
 > container workloads, the only two stable versions (with no critical
 > bugs) of Docker that we have been able to find were early 2017 or 2018.03-rc1.

That sounds pretty horrible :/


 > 2018.03-rc1 will be released as a full release soon as 2018.02 was
 > completely unusable due to a "container already exists" error when
 > trying to start a container.

 > If you would like me to make another series based around 17.12.1-ce that
 > was just released, I would be happy to do so.

Well, only if it actually works. But if you think there will be a new
(working) stable release before our next release (E.G. by April) then
I'm also fine with going with this 2018.03 version.
Christian Stewart March 1, 2018, 7:06 p.m. UTC | #4
Hi Peter,

Peter Korsgaard <peter@korsgaard.com> writes:
>>>>>> "Christian" == Christian Stewart <christian@paral.in> writes:
>  > 2018.03-rc1 will be released as a full release soon as 2018.02 was
>  > completely unusable due to a "container already exists" error when
>  > trying to start a container.
>
>  > If you would like me to make another series based around 17.12.1-ce that
>  > was just released, I would be happy to do so.
>
> Well, only if it actually works. But if you think there will be a new
> (working) stable release before our next release (E.G. by April) then
> I'm also fine with going with this 2018.03 version.

It's probably best to merge this to next for now (or wait until 2018.03
is released) and plan for the next stable release (2018.03) to include
in the next Buildroot stable.

I'll test the stability of the other release this weekend as well.

Best,
Christian