FS#49207 - [docker] 1.11 built with go-1.6 doesn't support older clients

Attached to Project: Community Packages
Opened by patrick (brisbin33) - Wednesday, 04 May 2016, 12:52 GMT
Last edited by Sébastien Luttringer (seblu) - Saturday, 18 June 2016, 00:32 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Sébastien Luttringer (seblu)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

With 1.11, the docker team wanted to build against go 1.6 (latest).

This doesn't work with clients <1.10, which were built against go <1.6 due to a difference in how Hosts are validated (causing the docker domain socket to be considered invalid).

Details: https://github.com/docker/docker/issues/20865

This was fixed upstream by downgrading docker-1.11 back to go-1.5

Details: https://github.com/docker/docker/pull/21489

It seems the Arch package produces a binary built against go 1.6:

% docker version
Client:
Version: 1.11.1
API version: 1.23
Go version: go1.6.2
Git commit: 5604cbe
Built: Mon May 2 00:06:51 2016
OS/Arch: linux/amd64

Server:
Version: 1.11.1
API version: 1.23
Go version: go1.6.2
Git commit: 5604cbe
Built: Mon May 2 00:06:51 2016
OS/Arch: linux/amd64

And so we still have this bug causing older clients to fail.


Steps to reproduce:

% pacman -S docker
% curl -o docker-1.9 https://get.docker.com/builds/Linux/x86_64/docker-1.9.0
% ./docker-1.9 version
Client:
Version: 1.9.0
API version: 1.21
Go version: go1.4.3
Git commit: 76d6bc9
Built: Tue Nov 3 19:20:09 UTC 2015
OS/Arch: linux/amd64
Error response from daemon: 400 Bad Request: malformed Host header


Additional information:

Yes, it's true that always using the same Arch-built binary for client and server avoids this issue. However, there can be reasons to use a different client than that which is locally installed. For example, the Code Climate CLI embeds a docker binary that it uses. It embeds 1.6 to be compatible with the widest range of servers. This breaks against an Arch-built server.

I'm curious why the Arch package doesn't download and install a pre-built binary instead of making one itself. That would be one solution to this problem, and seems more in line with the distribution intentions of upstream.
This task depends upon

Closed by  Sébastien Luttringer (seblu)
Saturday, 18 June 2016, 00:32 GMT
Reason for closing:  Upstream
Comment by patrick (brisbin33) - Sunday, 08 May 2016, 23:38 GMT
FWIW, I've attached a PKGBUILD that installs the pre-built binary (and solves this bug for me).

Note: I had some trouble using this binary at first. The daemon wouldn't start, complaining "error initializing graphdriver: driver not supported". I believe this was just a latent issue in my own setup (the projects I develop thrash the container graph pretty hard, and I've had things like this crop up before), and it was solved by wiping /var/lib/docker. I can't really see how something like that could be caused just by moving to the pre-built binary, but nevertheless, it's something to watch out for.
   PKGBUILD (2.3 KiB)
Comment by Doug Newgard (Scimmia) - Monday, 09 May 2016, 00:00 GMT
pre-built binaries are a last resort, not the preferred answer.
Comment by patrick (brisbin33) - Monday, 09 May 2016, 00:08 GMT
I also figured out the trouble I was having with this binary initially, and it is relevant. Seems the static binaries lack udev sync and therefore won't start with devicemapper as the storage driver (the default). I had coincidentally moved to overlayfs to silence a bunch of other log noise devicemapper causes, and that got things working. That's probably not viable for the general PKGBUILD since changing storage drivers requires wiping your /var/lib/docker.

I think the only solution is to change things such that it builds against go-1.5, like upstream does.
Comment by patrick (brisbin33) - Thursday, 09 June 2016, 14:25 GMT
FWIW: updating the makedepends to go<2:1.6, downgrading go locally, then re-building the docker package solved the issue. This would be annoying for the maintainer but doesn't impact users -- maybe it's a good solution?
Comment by Sébastien Luttringer (seblu) - Friday, 10 June 2016, 05:31 GMT
I remember upstream contacted me when I pushed docker 1.10 with go 1.6. They had issue with this version of go and asked to wait for 1.11.
Since then several release of 1.11 happened and so far, it works between Arch versions.

Here you have backward compatibility issues between docker client/server versions when they talk with the unix socket, triggered either by using an outdated Arch docker version (we don't support that) or by using another docker from another distro.

There is a patch proposed upstream to workaround this but they didn't include it in their maintenance release. I don't know why they consider the compiler has the key of their backward/cross compatibility, but we will not go in the past for that.

Deal with upstream to ensure several docker client/server can talk together with the unix socket. Compiler should not be the cause of such thing.

Loading...