Removal of the -f flags in docker tag break compatibility with server 1.9.x

[ggtools]

Recent versions of docker client support the DOCKER_API_VERSION variable to communicate with older servers. This is a very important features as it allows, in my case, to add a docker command in an image and to use this image regardless of the server version.

In my case I use a 1.12.x client with a 1.9.1 server downgrading the client API to version 1.21. When moving a tag I face two incompatible issues:

• the client does not accept flag -f as has been removed from the command arguments
• the server refuses to move the tag without a -fflag.

Steps to reproduce the issue:

1. Install a docker server in version 1.9.1
2. Get a client in version 1.12
3. Tag any image with any tag: DOCKER_API_VERSION=1.21 docker tag debian gruik
4. Try to move this tag with -f: DOCKER_API_VERSION=1.21 docker tag -f python gruik
5. Try to move this tag without -f: DOCKER_API_VERSION=1.21 docker tag python gruik

Describe the results you received:

At step 4:

unknown shorthand flag: 'f' in -f
See 'docker tag --help'

At step 5:

Error response from daemon: Conflict: Tag gruik:latest is already set to image xxxxx, if you want to replace it, please use -f option

Describe the results you expected:

Either step 4 or step 5 working or at least have the docker client refuses to downgrade to API version 1.21 on any command to be aware of the issue sooner.

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker version:

Client:
 Version:      1.12.3
 API version:  1.21
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 22:07:18 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.2
 Git commit:   a34a1d5
 Built:        Fri Nov 20 13:25:01 UTC 2015
 OS/Arch:      linux/amd64

Output of docker info:

cannot copy and paste from server and too long to copy, sorry

Additional environment details (AWS, VirtualBox, physical, etc.):

Server on Redhat Enterprise

[ggtools]

@GordonTheTurtle version/1.9 label is probably not really accurate as the issue is caused by a mix of client 1.12 & server 1.9 and the fix is probably more in version 1.12 than in version 1.9.

Yes I know I'm speaking to a turtle-bot ;)

[thaJeztah]

This flag was deprecated in a year ago in version 1.10 (#18350), and removed in 1.12 (#23090) according to our deprecation policy (/~https://github.com/docker/docker/blob/v1.12.0/docs/deprecated.md#-f-flag-on-docker-tag)

or at least have the docker client refuses to downgrade to API version 1.21

Note that the DOCKER_API_VERSION option is really intended as a debugging option, and will not change the behavior of the command line itself; the unknown shorthand flag: 'f' in -f option is an error generated by the client (the API will ignore the ?force=1 option on newer API versions)

Docker 1.13 and up will natively support API version negotiation, and allow downgrading to an older API version (but only two versions IIRC).

For this situation, I suggest using a docker 1.9 client, which should allow you to talk to both 1.9 and 1.12 daemons

[ggtools]

I'm ok with the principle of a server too old for the client (and the opposite). I'll check with 1.13 when I have the opportunity and I hope it'll report an error when the negotiation is not possible.

I do understand that DOCKER_API_VERSION is a debugging tool but you know, once the cat's out of the bag it's really hard to put it back in.

I'll close this and will open something for 1.13 if there is no error message in my case.

[thaJeztah]

@ggtools docker 1.13 will initially only automatically downgrade to API version 1.24 (corresponding with docker 1.12), docker 1.14 will support both 1.24, 1.25, and 1.26.

Note that no check is added to DOCKER_API_VERSION; that remains an option for debugging, so no special handling for older API versions is added

/cc @vieux