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 /version to server and check it in client. #627

Merged
merged 1 commit into from
Jul 30, 2014

Conversation

lavalamp
Copy link
Member

Will help detect client/version skew and prevent e2e test from passing
while running a version other than the one you think it's running.

func Get() (major, minor, gitCommit string) {
return "v1beta", "1", commitFromGit
type Info struct {
Major string
Copy link
Contributor

Choose a reason for hiding this comment

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

yaml/json tags?

Copy link
Member Author

Choose a reason for hiding this comment

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

Done, though I'm not sure it matters. I didn't make this an API object... I can do that, though, if you think it's better.

Copy link
Contributor

Choose a reason for hiding this comment

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

Probably worth doing that eventually (doesn't have to be this PR) since I think we will eventually split API + Client away from the "core" librararies, since many people will only want to build the client libs.

@lavalamp
Copy link
Member Author

I moved the implementation from kubecfg to client. Components besides kubecfg might also want to protect against version skew.

@brendandburns
Copy link
Contributor

LGTM

@smarterclayton
Copy link
Contributor

@lavalamp given #635 should this be under the api/ segment? Also, if I have 3 API versions active at a time (v1beta1, v1beta2, v1), will this always return the most recent version? How do I determine what API versions a server offers?

@lavalamp
Copy link
Member Author

@smarterclayton I was thinking of this more like a build number; this is the binary version, not the API version. Open to suggestions to make that clearer. (Maybe make it not sound similar?)

@smarterclayton
Copy link
Contributor

Isn't the whole point of API versioning and enforced backwards compatible changes to allow the kubecfg and apiserver binary versions to drift? Making it check as default seems very restricting - what if we run two apiservers from different code versions? A caching apiserver compiled by team X and the original by team Y? Will kubecfg reject my requests randomly if the server is in the middle of a rolling update when I get balanced to a particular server? If I'm using kubecfg to update a docker image running the apiserver on top of a kubelet, should kubecfg fail?

Seems like this is something that our test cases and test environments would leverage, but other than that would be uncommonly used outside of that. That's why I picked up on the similarity to the api version because that's what I assumed it was doing.

@lavalamp
Copy link
Member Author

All good points. You're right, checking by default is much too restrictive. I'll reverse the flag.

@lavalamp
Copy link
Member Author

Comments addressed, PTAL.

templateFile = flag.String("template_file", "", "If present, load this file as a golang template and use it for output printing")
templateStr = flag.String("template", "", "If present, parse this string as a golang template and use it for output printing")
versionFlag = flag.Bool("V", false, "Print the version number.")
serverVersion = flag.Bool("SV", false, "Print the server's version number.")
Copy link
Contributor

Choose a reason for hiding this comment

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

SV leaves a bad taste in my mouth - posix long arguments are always lowercase. How about 'server_version' (how often will someone call this)? Kind of a nit though.

@smarterclayton
Copy link
Contributor

LGTM besides nits - -SV is the only one I feel weird about.

@lavalamp
Copy link
Member Author

Nits fixed.

@smarterclayton
Copy link
Contributor

One more - I think we should add -expect_version_match to hack/test-cmd.sh

Will help detect client/version skew and prevent e2e test from passing
while running a version other than the one you think it's running.
@lavalamp
Copy link
Member Author

OK, done.

@smarterclayton
Copy link
Contributor

LGTM

@lavalamp
Copy link
Member Author

I'm gonna self-merge this later if no one beats me to it.

smarterclayton added a commit that referenced this pull request Jul 30, 2014
Add /version to server and check it in client.
@smarterclayton smarterclayton merged commit dc6fdc4 into kubernetes:master Jul 30, 2014
@smarterclayton
Copy link
Contributor

Saved you from taking the blame on a self merge break

vishh pushed a commit to vishh/kubernetes that referenced this pull request Apr 6, 2016
Add a v2 client library, starting with machine information.
mqliang pushed a commit to mqliang/kubernetes that referenced this pull request Dec 8, 2016
mqliang pushed a commit to mqliang/kubernetes that referenced this pull request Mar 3, 2017
Miciah pushed a commit to Miciah/kubernetes that referenced this pull request Apr 17, 2021
Bug 1949661: UPSTREAM: <carry>: management pinning annotations
linxiulei pushed a commit to linxiulei/kubernetes that referenced this pull request Jan 18, 2024
Add medik8s.io to Remdy Systems section
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants