Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a DOCKER_API_VERSION env var #15964

Merged
merged 1 commit into from
Dec 16, 2015
Merged

Add a DOCKER_API_VERSION env var #15964

merged 1 commit into from
Dec 16, 2015

Conversation

duglin
Copy link
Contributor

@duglin duglin commented Aug 31, 2015

Closes: #11486

Just for @ahmetalpbalkan :-)

Added DOCKER_API_VERSION env var and ApiVersion property in docker's config.json.

Cleaned up some comments that were > 80 chars.

Signed-off-by: Doug Davis dug@us.ibm.com

@thaJeztah
Copy link
Member

@duglin would this be something the client-config could be useful for?

@duglin
Copy link
Contributor Author

duglin commented Aug 31, 2015

@thaJeztah good point - forgot that it should be an option in there too... will work on that in a bit.

@ahmetb
Copy link
Contributor

ahmetb commented Aug 31, 2015

@thaJeztah
Copy link
Member

Awwwwwwww, LOL

@duglin duglin force-pushed the APIVersion branch 2 times, most recently from 642d8ac to cf20009 Compare September 1, 2015 00:22
@duglin
Copy link
Contributor Author

duglin commented Sep 1, 2015

ok added the config file property.

@@ -105,7 +112,8 @@ Following is a sample `config.json` file:
"HttpHeaders": {
"MyHeader": "MyValue"
},
"psFormat": "table {{.ID}}\\t{{.Image}}\\t{{.Command}}\\t{{.Labels}}"
"psFormat": "table {{.ID}}\\t{{.Image}}\\t{{.Command}}\\t{{.Labels}}",
"ApiVersion": "1.19"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be just GitHub, but the indentation looks off here (tabs/spaces?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yea there was a tab in there - fixed.

@thaJeztah
Copy link
Member

Thanks @duglin! Added some comments

@calavera
Copy link
Contributor

calavera commented Sep 1, 2015

If we do this, I think we should check that the version set by the user is lower than the client version, just in case.

@calavera
Copy link
Contributor

calavera commented Sep 1, 2015

I'm not completely fond of the env var, but I understand that it can be useful for automation.

@duglin duglin force-pushed the APIVersion branch 2 times, most recently from 2e6a39c to dd4d6b5 Compare September 1, 2015 11:53
@duglin
Copy link
Contributor Author

duglin commented Sep 1, 2015

aside from the 'XXX' string I mentioned before, I can see using this to test some v "2.0" APIs before they're officially in the build (e.g. I only have it enabled for certain APIs so I don't want to change ALL docker calls to 2.0 - just some via env var). So checking for a version string <= current version would be too limiting.

@tiborvass
Copy link
Contributor

I don't understand the usecase for an envvar

@ahmetb
Copy link
Contributor

ahmetb commented Sep 4, 2015

@tiborvass head over to #11486.

@icecrime
Copy link
Contributor

icecrime commented Oct 8, 2015

Sorry, meant to comment on the PR, please see here: #11486 (comment)

@icecrime
Copy link
Contributor

Still very much not convinced... But I guess: design LGTM assuming this remains a debugging tool.

@tiborvass
Copy link
Contributor

I found a usecase: allow people to have a quick workaround for scripts using the docker CLI and that are expecting output from older API versions such as for docker inspect -f ... that is always dependent on the latest API version.

@tiborvass
Copy link
Contributor

I would be fine with the envvar, but I don't see a need for the docker config.

@tiborvass
Copy link
Contributor

@duglin I suggest to have a Version field in api/client.DockerCli and also one of the following:

  1. Keep the Version constant in api/common.go, and set DockerCli.Version's default to api.Version
  2. Same as 1, but rename api.Version to api.ServerVersion or api.DefaultVersion
  3. Move Version constant to api/server, and set the default of DockerCli.Version manually to the same number as api/server.Version, but add a test to make sure the defaults are always equal for the server and the client.

Closes: moby#11486

Just for @ahmetalpbalkan  :-)

Fixed some comment formatting too while in there.

Signed-off-by: Doug Davis <dug@us.ibm.com>
@duglin
Copy link
Contributor Author

duglin commented Dec 14, 2015

@tiborvass I went with your 2nd option. Option 3 was really tempting but I couldn't bring myself to define the same value twice at this time. If we ever do move the cli into a separate repo then option 3 might make more sense.

However, as for option 2 (and 1), I came across an example of why this still bugs me. Look at:
https://github.com/docker/docker/pull/15964/files#diff-1d801b8b2dcffcde77b5995194bb3171L60
Notice I switched the reference from api.Version to use the cli's version. Sounds good (I hope). However, I think its important to ask how I knew to even change that at all? This PR was all about changing the URL's version string, which means I could have very well just changed the stuff here: https://github.com/docker/docker/pull/15964/files#diff-bcf4431eed51e55b4dca7deafdca48b0L106 and its possible the PR would have been merged and @ahmetalpbalkan would have been happy.

But, I just happen to know/remember that docker version also printed a version string. So, if no reviewer happened to remember that api.Version was use in this other spot then we would have missed this use of api.Version. Having the same info available at two locations is asking for this type of situation to happen again. Maybe it'll never happen, and maybe the next time someone adds a client-side reference to api.DefaultVersion someone will hopefully remember to use the cli.client.ClientVersion() method instead, but counting on hope makes me uncomfortable. But, its time to move on....

@calavera ready for review

@calavera
Copy link
Contributor

I like it. Thanks @duglin.

LGTM.

@runcom
Copy link
Member

runcom commented Dec 16, 2015

This will allow anyone to have docker installed on their systemd (say 1.10-dev) and a docker machine with 1.9.1. This way we won't get anymore Error response from daemon: client is newer than server (client API version: 1.22, server API version: 1.21)

LGTM, moving to doc review
ping @thaJeztah

@@ -38,6 +38,7 @@ the [installation](../../installation/index.md) instructions for your operating
For easy reference, the following list of environment variables are supported
by the `docker` command line:

* `DOCKER_API_VERSION` The API version to use (e.g. `1.19`)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per earlier discussions (e.g., "advanced/power user feature", no validation of the format, overriding the API version can lead to unexpected results), should we add a warning here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't think its necessary since people would need to go out of their way to make this happen so they should already know the risks.

Besides, I wouldn't want the warning message to interfere with any expected output.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, sorry, didn't mean a warning on the command line (that was discussed), but something in the docs. Do you think that's redundant?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yea, I think it would be redundant.

@tiborvass
Copy link
Contributor

@duglin can't we write a test (unit?) to ensure the two versions are the same?

@duglin
Copy link
Contributor Author

duglin commented Dec 16, 2015

@tiborvass I'm not sure how a unit test will help find uses of api.DefaultVersion that should really be cli.client.ClientVersion().

@thaJeztah
Copy link
Member

Alright, let's not uphold this PR by additional warnings in the docs.

docs LGTM

@calavera
Copy link
Contributor

docs, (or lack of them :trollface:) LGTM. Merging 🎉

calavera added a commit that referenced this pull request Dec 16, 2015
Add a DOCKER_API_VERSION env var
@calavera calavera merged commit 905f333 into moby:master Dec 16, 2015
@thaJeztah thaJeztah added this to the 1.10 milestone Dec 16, 2015
@ahmetb
Copy link
Contributor

ahmetb commented Dec 16, 2015

yayy! thanks y'all

@runcom
Copy link
Member

runcom commented Dec 17, 2015

🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants