6 ms·

You're missing the fact that docker clients complain about the API version if they're different from the server - regardless of actual compatibility problems.

by web007 10y ago

You're missing the fact that docker clients complain about the API version if they're different from the server - regardless of actual compatibility problems. http://stackoverflow.com/questions/37617400/ http://stackoverflow.com/questions/37617400/ sums it up. There's a magic (afaik undocumented) env var DOCKER_APIVERSION you can set for compatibility, but nobody can find it. If you can't mix even minor versions then yes, it's a problem. I can't run X in prod and anything other than X in dev of I'm working with the same toolset.

teabee89 10y ago
The issue you are referring to happens only if the docker client version is newer than the docker daemon version. In the case where the client is older than the daemon, it has always worked. Thanks for bringing this issue up though, because we are currently working on a fix. Here is the PR: https://github.com/docker/docker/pull/27745 https://github.com/docker/docker/pull/27745 As for DOCKER_API_VERSION, it is possibly not well documented, but it is indeed present in the documentation: https://docs.docker.com/engine/reference/commandline/cli/ https://docs.docker.com/engine/reference/commandline/cli/ Hopefully this was helpful.
- web007 10y ago
  The client will nearly always be newer, so that message will almost always show up. You'll update your laptop tools regularly, and only bump your infrastructure occasionally. How many versions has this been a problem? It's not thinking about things like this until (apparently) 11 days ago that give Docker haters such ammo. The UX of the entire ecosystem feels like an afterthought. Yes, it's been evolving rapidly, but that's no excuse for not having a good, unified user experience for what's there or what's coming next.
  - cpuguy83 10y ago
    That's a fair statement, especially with d4mac/d4win and auto-update. Posting a pull request and thinking about a problem are two very different things. The project has chosen to err on the side of safety (ie, user asked for some feature to be used but it is silently ignored since it's connecting to an older daemon) in this regard. -- this is not the only problem to solve

by web007 10y ago

teabee89 10y ago

The issue you are referring to happens only if the docker client version is newer than the docker daemon version. In the case where the client is older than the daemon, it has always worked. Thanks for bringing this issue up though, because we are currently working on a fix. Here is the PR: https://github.com/docker/docker/pull/27745 https://github.com/docker/docker/pull/27745 As for DOCKER_API_VERSION, it is possibly not well documented, but it is indeed present in the documentation: https://docs.docker.com/engine/reference/commandline/cli/ https://docs.docker.com/engine/reference/commandline/cli/ Hopefully this was helpful.

web007 10y ago
The client will nearly always be newer, so that message will almost always show up. You'll update your laptop tools regularly, and only bump your infrastructure occasionally. How many versions has this been a problem? It's not thinking about things like this until (apparently) 11 days ago that give Docker haters such ammo. The UX of the entire ecosystem feels like an afterthought. Yes, it's been evolving rapidly, but that's no excuse for not having a good, unified user experience for what's there or what's coming next.
- cpuguy83 10y ago
  That's a fair statement, especially with d4mac/d4win and auto-update. Posting a pull request and thinking about a problem are two very different things. The project has chosen to err on the side of safety (ie, user asked for some feature to be used but it is silently ignored since it's connecting to an older daemon) in this regard. -- this is not the only problem to solve