-
Notifications
You must be signed in to change notification settings - Fork 18.7k
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
Conversation
@duglin would this be something the client-config could be useful for? |
@thaJeztah good point - forgot that it should be an option in there too... will work on that in a bit. |
Awwwwwwww, LOL |
642d8ac
to
cf20009
Compare
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" |
There was a problem hiding this comment.
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?)
There was a problem hiding this comment.
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.
Thanks @duglin! Added some comments |
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. |
I'm not completely fond of the env var, but I understand that it can be useful for automation. |
2e6a39c
to
dd4d6b5
Compare
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. |
I don't understand the usecase for an envvar |
@tiborvass head over to #11486. |
Sorry, meant to comment on the PR, please see here: #11486 (comment) |
Still very much not convinced... But I guess: design LGTM assuming this remains a debugging tool. |
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 |
I would be fine with the envvar, but I don't see a need for the docker config. |
@duglin I suggest to have a
|
Closes: moby#11486 Just for @ahmetalpbalkan :-) Fixed some comment formatting too while in there. Signed-off-by: Doug Davis <dug@us.ibm.com>
@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: But, I just happen to know/remember that @calavera ready for review |
I like it. Thanks @duglin. LGTM. |
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 LGTM, moving to doc review |
@@ -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`) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
@duglin can't we write a test (unit?) to ensure the two versions are the same? |
@tiborvass I'm not sure how a unit test will help find uses of api.DefaultVersion that should really be cli.client.ClientVersion(). |
Alright, let's not uphold this PR by additional warnings in the docs. docs LGTM |
docs, (or lack of them ) LGTM. Merging 🎉 |
Add a DOCKER_API_VERSION env var
yayy! thanks y'all |
🎉 |
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