docker in 14.04

[James Page]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi Technical Board

On 07/12/14 07:45, Martin Pitt wrote:
>> 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?
> I'd prefer limiting the number of parallelly supported versions,
> too. I guess the answer depends on whether the next docker version
> is fully backwards compatible with existing installs. I. e. if we
> update docker-current from 1.4 to 1.5, does that break existing
> installs? If so, then this isn't feasible and we need to start a
> new series. But if it is compatible I see little reason for keeping
> the old 1.4 then?

Pat and I met with Eric Windisch (CC'ed) from upstream Docker
yesterday and had a good conversation about how upstream are managing
their releases and what policy they are applying for things like
security updates.

Right now, they have two active releases:

   1.3 - current stable
   1.4 - next stable

Docker released 1.4 and updates to 1.3 (1.3.3 - to fix security issues
- - see [0]) at the same time, but once stable switches to a new
release, they currently no longer backport security fixes to the old
stable release.

So the current recommendation to fix security issues to to upgrade to
the latest stable, which will have the required fixes.  Yikes....

We (as in the Canonical Server team) considered whether we would be
able to backport security fixes to the version we released with in
14.04 (1.0.1), but the key challenge with docker is that its an
extremely fast moving project still; the amount of code churn from
1.0.1 -> 1.3.3 is vast, making back-porting of security and critical
bug fixes a high regression risk (reminds me of jenkins for some
reason - but at least docker don't release weekly).

Associated with Martin's point about upgrades, we are concerned about
backwards compatibility between versions as well - specifically for
tooling that uses the docker API; for the docker client itself we can
resolve, and we don't have anything in the distro that actually used
the docker API (at least for 14.04 - that changed in 14.10).

I'm also keen that we keep deployment repeatable, meaning that an end
user of the Ubuntu docker packages can deploy and expand capacity
without worrying (within reason) that they are suddenly going to have
a version mismatch on the new servers they just added.

For these reasons, I'm proposing the approach of maintaining three
docker versions at any given point in time.

Specifically:

	- unstable - the next stable release
	- stable - the current stable release
	- oldstable - the previous stable release

in docker versions today, this would equate to:

	- unstable - 1.4.1
	- stable - 1.3.3
	- oldstable - 1.0.1 (or 1.2.2)

Each of those versions is delivered via a versioned package:

	- docker.io-1.4
	- docker.io-1.3
	- docker.io-1.2

with separate meta packages to support:

	- docker.io-unstable -> docker.io-1.4
	- docker.io-stable -> docker.io-1.3
	- docker.io-oldstable -> docker.io-1.2

Once a docker-io-X.Y package is no longer referred to by a meta
package, it gets removed from the archive and is no longer installable.

So this allows end-users to manage their migration between versions,
by directly using the docker.io-X.Y packages, OR track what we
consider to be 'stable' or 'unstable' (if people really want to bleed).

Hopefully this approach addresses the concerns around

1) upgrades

We should always have an upgrade path for docker users in the archive.

2) security issues

We fix security issues by either a) patching the current stable or b)
switching to the new stable (if appropriate), rippling the versions
and then notify users to plan their upgrades accordingly.

3) maintainability

Three versions at any one time, along with a level of automation
around cutting new package versions and upgrade testing, should be
maintainable.

4) repeatable deployments

Users can stick to a specific versioned package if need be for
repeatable deployment; however we should set expectation that the
lifetime of a minor release is going to be around 5 months (going on
past history [1] - this may extend if upstream slow down a bit).

Anyway that's my current thinking on how we balance the traditional
distro approach with the fast pace of obsolescence with a project like
docker.

Regards

James

PS: As a side note, 1.0.1 in 14.04 and 1.2.x in 14.10 both currently
have critical security vulnerabilities - see [2].  The plan currently
is to update to 1.3.3.


[0]
http://blog.docker.com/2014/12/advancing-docker-security-docker-1-4-0-and-1-3-3-releases/
[1] https://github.com/docker/docker/releases
[2] https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1396572

- -- 
James Page
Ubuntu and Debian Developer
james.page at ubuntu.com
jamespage at debian.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJUkw+jAAoJEL/srsug59jDMAcQAKji+3/XwW3BpPUoG0Uy8IkN
80zTzjyJ2lVhu75HpPgJQVSs3rNsLezLV1LpyJdkmKfuPP07PSmdppVPNt5E8gPb
+NTuwtDOS7dTqwjmL/lyL00mpOKJjkiahfzAKuFIsTW6d/Nq2TafZEJxQuPnUkpq
XfU/TMOxaX+w6j3QyFyFmHN4mhj3BcyQM0LExK6eH7N1/lAOXiIa91Yqi0KHSfcs
eSTysH7svXnuwqijRT6VWzAFsijhSdYN3Mkum71XF4M4G10edfkmjVovoW6iNe9L
AHsNKQNcEtP3hr7FZFaCPLftH/mLTHw0y2m3y0E+AnT1LXwcjP8ThbOO4+wA5jqx
aQs0V1rPD1sfzsWTel7RkzPYePtssxK8y9YhAJ9WS+BRdaHABuWZSuU/bQq2igd3
f+BWUtPk+aK15n+QVe717pwoco0iIW7bWmCUQWUn96n8Km5P2XV0Sl/eOCKQlWV6
38tIdWEzUTQ93IpfWmjNBA1huk6bcKJff5E9Ljo8rTWM2OU7LncQuab5yBFDzCjL
8m3qQA1qBhhOU3uY/xgQFZ7R1iuKegWiBwsK6V97mKrUOIdCE++d5+Pom42YA3Pp
kylUxf7R1F1O48XMqeJr6YAoWGlUgGGt92Kn8kyxozQQ2ZeF14VN+MuTj+TORg7z
ugy1WRWJulTg5KmbSy3E
=xXKe
-----END PGP SIGNATURE-----