Add the used Kubernetes Version to kudo version output
#1671
Conversation
Signed-off-by: Andreas Neumann <aneumann@mesosphere.com>
ANeumann82
requested review from
alenkacz,
gerred,
kensipe,
nfnt and
zen-dog
as code owners
Signed-off-by: Andreas Neumann <aneumann@mesosphere.com>
There was a problem hiding this comment.
This is great stuff and a welcomed addition... my issue with it is the naming of things (including the title of the PR). I'm against the use of the word kubernetesapi it is not. It is a kubernetes version which very indirectly supports an api. I see that you are getting the version of the API from k8s.io/api so it seems like it defines the API... but this is a client side dependency. The real API is at the server.
The version of k8s.io/api is selected when we bump the client-go library and we keep those in-sync. I wonder if it would be better to expose our client-go version or this "k8s api version" as the client-go version... then people will have somewhere to go to understand the mapping to their server version.
If we don't change to client-go version... then I do feel like we need to express this NOT as a kubernetes API version... but as a client kubernetes API version (which could be confusing... although accurate and seemingly necessary)
| GitVersion: gitVersion, | ||
| GitCommit: gitCommit, | ||
| BuildDate: buildDate, | ||
| GoVersion: runtime.Version(), | ||
| Compiler: runtime.Compiler, | ||
| Platform: fmt.Sprintf("%s/%s", runtime.GOOS, runtime.GOARCH), | ||
| } | ||
|
|
||
| if info, ok := debug.ReadBuildInfo(); ok { |
There was a problem hiding this comment.
I haven't looked into it.. but I'm also questioning if this complexity of reading build info at runtime is necessary. It seems clever... but it is a very indirect way to have a dependency. not that this is likely to happen... but what if the dependency is removed or the naming changes... This is fine if there is no other way.. but is there a way to get the version directly from client-go?
There was a problem hiding this comment.
I don't think there is a way to get the version directly from client-go. There is a version package inside, but using
version.Get().GitVersion results in a string of "v0.0.0-master+$Format:%h$".
From what I read is the debug.ReadBuildInfo() the correct way to get information about the used modules.
There was a problem hiding this comment.
I agree with all that @kensipe said: We have to be clear here that this is the version of the Kubernetes client API and this isn't mistaken for the server API. No strong opinion around debug.ReadBuildInfo(), but if there's an easy way to retrieve the version directly from client-go, let's use that instead.
Use version from client-go library Signed-off-by: Andreas Neumann <aneumann@mesosphere.com>
ANeumann82
changed the title
kudo version output
I have renamed the field to I don't think it makes sense to expose this version as the Thankfully, all Kubernetes components are released together, so the Kubernetes 0.18.6 release contains the I think KubernetesVersion makes the most sense and helps users to understand, wdyt? |
There was a problem hiding this comment.
all the information here is low level... git commit, go version... this information could only be for devs or for us. If we are to enable others, the meaningful metadata is client-go. If they know that it is client-go, then they can go to client-go matrix which is maintained to understand consequences. Anything else likely has has us duplicating all the client-go stuff (please no) and requires some guessing or assumptions... which might sound something like: is this the version of the kubectl on my local machine.. I know my server is a different version. let me upgrade my client kubectl... wait that didn't do it... my client is 1.19.2, the server is 1.19.5... but kudo is reporting 1.18.5... what does that mean? how can I upgrade it?
It is better IMO to be clear when we can. why would we hide it? why make the user guess? why add another layer of translation? It isn't clear what it solves.
I expect all operators to have this need: 1. express what version of client-go they use and 2. what version of controller-runtime they use... which defines their constraints.
|
if you are trying to stay away from "ClientGo"... that makes sense! Could we call it "ClientKubernetesVersion" or "KubernetesClientGoVersion"... leaving the word kubernetes out wouldn't be good. ah... naming is hard and this is better than the previous options. Whatever you think is best. |
Signed-off-by: Andreas Neumann <aneumann@mesosphere.com>
|
Thanks. I see your point. I've renamed it to |
Signed-off-by: Andreas Neumann aneumann@mesosphere.com
What this PR does / why we need it:
This PR shows the used Kubernetes API in the version output. Helps users to understand which version of kubernetes is supported, see #1642