Error doing docker ps when client is newer about minishift HOT 11 CLOSED

Then an unfortunate Docker thing that you cant access older Docker daemons with newer client by default.

The quickest workaround ist to set DOCKER_API_VERSION:

 export DOCKER_API_VERSION=1.23

from minishift.

@jimmidyson maybe minishift docker-env could set this env var, too ?

from minishift.

FWIW, there is a direct corelation betwen API version number and Docker release number (which you can get from https://api.github.com/repos/boot2docker/boot2docker/releases when downloading the iso). Its not written in stone, but I think its safe to assume that the API version increases on the same footstep as the release numbe (i.e increasing the minor version number).

Here is the current mapping: https://docs.docker.com/engine/reference/api/docker_remote_api/

from minishift.

Is it safe to set that env var? Would there potentially be backwards compatibility issues? Would hope not but...

from minishift.

This variable works when using an older server with a new client and it instructs the client to use exactly this API level. Of course, it depends on the Docker CLI client whether it supports the 'old' API and of course newer API methods/parameters wont probably work. It would be nice if the client would degrade grafecully (saying sth 'this feature is not supported for this API level 'bla'), but not sure whether this is the case.

For basic operations (e.g. without using any Swarm functionality for Docker swarm 1.12) I guess it works correctly, but as it is only a guess, maybe its safer to not set it automatically (but document is somewhere).

from minishift.

Just tested a 1.12 client against 1.11 server -->

docker swarm init
No --secret provided. Generated random secret:
    8az4he1n4jdfodz9cl2l96e0m

Error response from daemon: 404 page not found

So not so gracefully ....

from minishift.

Not graceful, but not too worried about using newer functionality against older server version. More interested that what the server supports the client can handle correctly just by setting the client version env var. Seems to be the case

from minishift.

think, too, thats the case for >90% of the changes as from my experience there were only additions and no changes or removals of API methods, parameter keys, and return values keys. Would be interesting whether the client could cope with the rare cases which are really incompatible changes (so that it fallbacks to an old API client call when this env var is set to an older API).

from minishift.

Good way to discover the API version or just hard code it for now?

from minishift.

You can detect it live via <ip:port>/version but then you need already a running docker daemon.

Or you get the Docker version from boot2docker.iso's release file and then map this hardcoded to the API version by using the table in https://docs.docker.com/engine/reference/api/docker_remote_api/ (needs then to be updated for each Docker release).

from minishift.

Should be fixed now.

from minishift.