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
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
|
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
Saturday, 18 June 2016, 00:32 GMT
Reason for closing: Upstream
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.
I think the only solution is to change things such that it builds against go-1.5, like upstream does.
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.