-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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 Compatible Kubernetes to Version Printout #2446
Add Compatible Kubernetes to Version Printout #2446
Conversation
version/version.go
Outdated
Version = "v0.14.0+git" | ||
GitVersion = "unknown" | ||
GitCommit = "unknown" | ||
KubernetesVendorVersion = "unknown" |
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.
Since we technically support a range of k8s versions, it would be informative to print min and max k8s version variables:
$ operator-sdk version
operator-sdk version: "v0.14.0", commit: ..., minKubernetesVersion: "v1.14.0", maxKubernetesVersion: "v1.16.3"
This will reflect the eventual test and compatibility matrices we will be adding as follow-ups. WDYT?
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.
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.
Are we effectively trying to convey the information in the client-go compatibility matrix?
The problem with min and max versions is that the answer to the question "is my code compatible with my kubernetes server?" is "yes if you're using the same client and server version, maybe if your client and server versions differ by exactly 1, and otherwise there are no guarantees"
Because of those nuances, I would suggest that we just list our client-go dependency and add a link to our dependencies section over to the client-go compatibility matrix? WDYT?
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.
Yes that was the intent. The version from the client-go kubernetes-x.y.z
tag plus a link is a better approach to capture this information.
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.
We technically do support a range of k8s versions (i.e client-go matrix) but we don't really test against supposedly compatible k8s versions.
So I agree that linking to the client-go matrix as an indirect indication of compatibility is okay but probably not listing out the exact versions here since we haven't tested and guaranteed that the SDK works against all of them.
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.
So right now this would just be the k8s version in our CI K8S_VERSION
.
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.
Yep, that sounds good to me.
Ideally (possibly for a follow-on) we would enforce in CI that K8S_VERSION aligns with our client-go dependency. How doable would that be?
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.
Whatever we decide to include, we should auto-populate via ldflags from the Makefile. We'll need to add that before merging this.
version/version.go
Outdated
Version = "v0.14.0+git" | ||
GitVersion = "unknown" | ||
GitCommit = "unknown" | ||
KubernetesVendorVersion = "unknown" |
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.
Are we effectively trying to convey the information in the client-go compatibility matrix?
The problem with min and max versions is that the answer to the question "is my code compatible with my kubernetes server?" is "yes if you're using the same client and server version, maybe if your client and server versions differ by exactly 1, and otherwise there are no guarantees"
Because of those nuances, I would suggest that we just list our client-go dependency and add a link to our dependencies section over to the client-go compatibility matrix? WDYT?
cmd/operator-sdk/version/cmd.go
Outdated
@@ -31,7 +31,7 @@ func NewCmd() *cobra.Command { | |||
if version == "unknown" { | |||
version = ver.Version | |||
} | |||
fmt.Printf("operator-sdk version: %q, commit: %q, go version: %q\n", version, ver.GitCommit, ver.GoVersion) | |||
fmt.Printf("operator-sdk version: %q, commit: %q, kubernetes version: %q, go version: %q, bulid date: %q\n", version, ver.GitCommit, ver.KubernetesVendorVersion, ver.GoVersion) |
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.
fmt.Printf("operator-sdk version: %q, commit: %q, kubernetes version: %q, go version: %q, bulid date: %q\n", version, ver.GitCommit, ver.KubernetesVendorVersion, ver.GoVersion) | |
fmt.Printf("operator-sdk version: %q, commit: %q, kubernetes version: %q, go version: %q\n", version, ver.GitCommit, ver.KubernetesVendorVersion, ver.GoVersion) |
version/version.go
Outdated
Version = "v0.14.0+git" | ||
GitVersion = "unknown" | ||
GitCommit = "unknown" | ||
KubernetesVendorVersion = "unknown" |
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.
Maybe just KubernetesVersion
to align with what we output with operator-sdk version
?
Fixes #2118 While we can't have a compatibility matrix without actually testing the matrix first in CI, this should at least specify compatibility for a single version. |
Co-Authored-By: Joe Lanford <[email protected]>
… into k8sversion-print
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.
/lgtm
although I don't think this closes #2118 since we don't add what the issue author is asking for 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.
LGTM
@theishshah Can you also add a line to the CHANGELOG? |
New changes are detected. LGTM label has been removed. |
Description of the change:
Adding necessary fields to the verison, needs implementation on build side to populate.
The build implementation will involve passing along the required values in the ldflags field
Closes #2118