Bug 42282 - Update docker.io package to 1.12
Update docker.io package to 1.12
Product: UCS
Classification: Unclassified
Component: Docker
UCS 4.2
Other Linux
: P5 enhancement (vote)
: UCS 4.2
Assigned To: Stefan Gohmann
Dirk Wiesenthal
: interim-1
: 41285 43215 (view as bug list)
Depends on:
Blocks: 43842
  Show dependency treegraph
Reported: 2016-09-06 12:35 CEST by Arvid Requate
Modified: 2017-04-04 18:29 CEST (History)
8 users (show)

See Also:
What kind of report is it?: Feature Request
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?: Yes
Waiting Support:
Ticket number: 2016090521000549, 2016121621000441
Bug group (optional): External feedback, Release Goal, Security
Max CVSS v3 score:


Note You need to log in before you can comment on or make changes to this bug.
Description Arvid Requate univentionstaff 2016-09-06 12:35:47 CEST
We should consider updating the docker.io package from the Jessie version 1.6.2 to something newer. Debian Stretch (testing) currently ships 1.11.2. There are quite a couple of improvements in the upstream changelog:


I haven't evaluated the changelog fully yet, but something in the direction of content trust signing has been asked for by a customer (Ticket#2016090521000549). Docker 1.8 seems to provide that:

Comment 1 Stefan Gohmann univentionstaff 2016-09-21 21:51:22 CEST
*** Bug 41285 has been marked as a duplicate of this bug. ***
Comment 2 Arvid Requate univentionstaff 2016-12-19 11:40:13 CET
*** Bug 43215 has been marked as a duplicate of this bug. ***
Comment 3 Nico Gulden univentionstaff 2017-01-12 09:20:33 CET
For one app provider I do neeed at least docker version 1.10.
Comment 6 Stephan Brauer 2017-01-27 08:22:21 CET
I'd like to propose switching to 1.13; Mainly because it's the latest Version as of now, but 1.12 and 1.13 have very useful Features IMO.

1.12 Comes with the swarm mode, which is very handy for multiple host deployments, HA and rolling updates.

1.13 Brings nice cleanup tools (i.e. `docker system prune`). Breaks compatibility with the plugin API and all pre-1.13 installed plugins need to be installed again.

Generally, Docker seldom introduces regression in new releases and every release seems to be more stable.

We're seriously considering Docker at work (with swarm mode enabled) and it would be great to have it baked into UCS 4.2. Docker has Debian repositories for old-stable, stable and the next release, I guess that would packaging more easy and independent from debian-backports!? (see link by Stefan Gohmann).
Comment 7 Stefan Gohmann univentionstaff 2017-01-30 08:12:53 CET
Some more info about the "source packages": https://blog.docker.com/2015/07/new-apt-and-yum-repos/
Comment 8 Stefan Gohmann univentionstaff 2017-01-30 21:24:23 CET
I've imported and built the following packages from Debian Jessie Backports:
 - golang-1.6
 - runc
 - golang-codegangsta-cli
 - golang-github-coreos-go-systemd
 - golang-github-docker-go-units
 - golang-github-opencontainers-specs
 - golang-github-seccomp-libseccomp-golang
 - golang-github-vishvananda-netlink
 - dh-golang
 - golang-dbus
 - golang-github-xeipuuv-gojsonschema
 - golang-testify
 - golang-github-xeipuuv-gojsonreference
 - golang-github-xeipuuv-gojsonpointer
 - golang-github-davecgh-go-spew
 - golang-github-pmezard-go-difflib
 - golang-objx

From debian.snapshot.net golang in version 2:1.4.3-3~bpo8+1. This was necessary to build golang-1.6.

From Ubuntu:
- containerd
- docker.io (1.12.3)

So, I've decided to import the docker version from Ubuntu because docker in Debian is currently ony in sid. The Debian maintainer wrote in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850753#10:
The reason Ubuntu is able to be more aggressive than Debian is that
they've made an explicit release exception for using Docker's
published "vendor" directory as-is rather than splitting it out into
individual packages (which is what causes so much headache for us in
Debian every new Docker release, and causes a greater number of issues
such as #835686).

The docker-engine package directly from Docker can't be build in our buildsystem.

Maybe the Ubuntu package will be updated in the next weeks so that we can update to 1.13 in the UCS 4.2 final version.

Currently, I've disabled the docker.io testsuite (012_rules_disable_testsuite.patch). Otherwise the build fails with:
ok      github.com/docker/docker/profiles/seccomp       0.014s  coverage: 26.2% of statements
ok      github.com/docker/docker/reference      0.031s  coverage: 87.8% of statements
2017/01/30 15:03:28 http: TLS handshake error from remote error: bad certificate
2017/01/30 15:03:28 http: TLS handshake error from remote error: bad certificate
2017/01/30 15:03:28 http: TLS handshake error from remote error: bad certificate
--- FAIL: TestEndpoint (0.12s)
        registry_mock_test.go:263: Expected error while expanding bad endpoint: <nil> == <nil>
        registry_mock_test.go:263: Expected error while expanding bad endpoint: <nil> == <nil>
        registry_mock_test.go:263: Expected error while expanding bad endpoint: <nil> == <nil>
        registry_mock_test.go:263: Expected error while expanding bad endpoint: <nil> == <nil>
        registry_mock_test.go:263: Expected error while expanding bad endpoint: <nil> == <nil>
coverage: 51.9% of statements
FAIL    github.com/docker/docker/registry       0.218s
ok      github.com/docker/docker/restartmanager 0.002s  coverage: 46.9% of statements
ok      github.com/docker/docker/runconfig      0.017s  coverage: 62.8% of statements
ok      github.com/docker/docker/runconfig/opts 0.041s  coverage: 74.0% of statements
ok      github.com/docker/docker/utils  0.023s  coverage: 39.1% of statements
ok      github.com/docker/docker/utils/templates        0.003s  coverage: 50.0% of statements
ok      github.com/docker/docker/volume 0.022s  coverage: 61.0% of statements
ok      github.com/docker/docker/volume/drivers 15.012s coverage: 40.7% of statements
ok      github.com/docker/docker/volume/local   0.029s  coverage: 2.2% of statements
ok      github.com/docker/docker/volume/store   15.010s coverage: 59.7% of statements
?       github.com/docker/docker/volume/testutils       [no test files]
debian/rules:89: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
Comment 9 Stefan Gohmann univentionstaff 2017-01-30 22:00:30 CET
And two more packages from Jessie backports:
 - libseccomp
 - golang-github-vishvananda-netns 

I had to disable the test case TestRuleAddAndLoad in golang-github-seccomp-libseccomp-golang. It failed with this message:
=== RUN   TestMergeFilters
--- PASS: TestMergeFilters (0.00s)
=== RUN   TestRuleAddAndLoad
--- FAIL: TestRuleAddAndLoad (0.00s)
	seccomp_test.go:455: Syscall should have returned error code!
exit status 1
FAIL	github.com/seccomp/libseccomp-golang	0.003s

See also here:

Comment 10 Stefan Gohmann univentionstaff 2017-01-31 06:41:26 CET
Changelog via r76214.

I've created a new bug which should be checked after UCS 4.2 milestone 2: Bug #43449.
Comment 11 Dirk Wiesenthal univentionstaff 2017-02-08 10:04:20 CET
Changelog: OK
Package: OK

Note that after an update to 4.2, the docker CLI is unusable until restart (I simply restarted the machine). This may be a problem if the App Center is to be used immediately after an update.
Comment 12 Daniel Tröder univentionstaff 2017-02-08 10:40:57 CET
The CLI might be unusable, because the old daemon is still running. That could mean, that upon restart it cannot cleanly shutdown the containers and will simply kill them after a timeout.

Docker updates use a special setting to make an upgrade without shutting down the daemon (as it is usually done in Debian) so that the containers are not shutdown.
With a API-breaking upgrade, the usual stop-upgrade-start should be used. Then the CLI should work without a restart and the containers will be safe.
Comment 13 Stefan Gohmann univentionstaff 2017-04-04 18:29:24 CEST
UCS 4.2 has been released:

If this error occurs again, please use "Clone This Bug".