docker in 14.04

Marc Deslauriers marc.deslauriers at canonical.com
Fri Dec 5 12:46:08 UTC 2014


Hi Pat,

On 2014-11-13 07:13 PM, Patricia Gaughen wrote:
> Below is a proposal on how we'd like to bring the latest docker to the
> Ubuntu Server 14.04 LTS. I wanted to get feedback, and then after the
> feedback is resolved, support from the tech board on this proposal. As
> we pulled this proposal together we tried to balance the need to keep
> the LTS stable, but also to give our user base the latest and greatest
> docker as simply as possible.
> 
> 
> The Proposed Strategy
> 
> LTS release - provide version-ed package names for major and minor
> release changes, micro release changes will just be an update to the
> existing version  (i.e. the 1.3 release of docker’s package will be
> docker.io-1.3, and if there is a 1.3.1 release of docker it will be an
> update to docker.io-1.3.  When 1.4 releases, we will create a new
> package - docker.io-1.4). In addition, we will provide a meta package,
> docker.io-latest which will point to the latest version of docker.  If
> a user chooses to install using the meta package, they will get the
> latest version each time they update.
> 
>     - area of concern: dependencies. It is expected that during the
> LTS life cycle, docker may have dependency changes that will be
> problematic.  To address this, we're propsing including any new docker
> dependencies in the docker package, like what is done with juju.
> 
>    - area of concern: upgrades. An area of concern is upgrades of
> docker containers. In order to address this concern, we need to create
> an automated testing gate (until the gate is written it will be a
> manual test)  - if the package fails, it doesn't get through.
> 
> Development releases - we will bump the version of Docker in the
> development release as part of the normal process. We will not provide
> version-ed package names, nor a meta package.  Once the development
> release is shipped, new version will be pushed the next release.
> 
> Security and Bug fixes -  For both the LTS and Development releases,
> security and bug fixes will be provided through new upstream releases.
> 
> Docker Upgrade Test - Here’s what I'm thinking our automated testing
> gate would need to test (1) upgrade from the previous version to the
> new one (2) upgrade from release version to the new version.
> 

While I perfectly understand the required balance between keeping the LTS
stable, and being able to get the latest version of Docker in user's hands, I'm
not convinced packaging every single version of Docker for the next 5 years is
the best approach.

Users who are looking for a stable version of Docker are likely to want one that
is secure. A quick glance in the Docker mailing list shows that newer versions
are being released to handle security issues:

https://groups.google.com/forum/#!topic/docker-user/jyf9_mYcMI8
https://groups.google.com/forum/#!topic/docker-user/oYm0i3xShJU
https://groups.google.com/forum/#!topic/docker-user/IrjXTHA6jJc

If all we intend on doing is creating different packages for newer versions,
people using anything but the latest package, including users of the stable
release, will be running Docker in an insecure manner with known security
vulnerabilities.

Wouldn't it be simpler to maintain two docker packages in the LTS release, one
that is stable to which security fixes get backported (in the case of trusty, it
looks like it's currently 1.0.1), and a second one that is always the latest
version? Is there any value in maintaining a multitude of packages with known
vulnerabilities in the archive?

Marc.




More information about the technical-board mailing list