kubernetesVersion doesn't work for kubernetes with complex version string

[scaleoutsean]

This is like #6190 except that was fixed by adding -0 (v1.xx.x-0) which doesn't seem to work for more complex version strings like v1.20.2-34+350770ed07a558:

$ helm install trident trident-operator --namespace trident --create-namespace 
Error: chart requires kubeVersion: >= v1.16.0,< v1.21 which is incompatible with Kubernetes v1.20.2-34+350770ed07a558

Output of helm version:

$ helm version
version.BuildInfo{Version:"v3.5.2", GitCommit:"167aac70832d3a384f65f9745335e9fb40169dc2", GitTreeState:"dirty", GoVersion:"go1.15.7"}

Output of kubectl version:

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"20+", GitVersion:"v1.20.2-35+e99a4bd69e2a3e", GitCommit:"e99a4bd69e2a3ead8f02ace985c3c1363dc7abf6", GitTreeState:"clean", BuildDate:"2021-02-12T20:05:15Z", GoVersion:"go1.15.8", Compiler:"gc", Platform:"linux/arm64"}
Server Version: version.Info{Major:"1", Minor:"20+", GitVersion:"v1.20.2-35+e99a4bd69e2a3e", GitCommit:"e99a4bd69e2a3ead8f02ace985c3c1363dc7abf6", GitTreeState:"clean", BuildDate:"2021-02-12T19:56:07Z", GoVersion:"go1.15.8", Compiler:"gc", Platform:"linux/arm64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.):

• MicroK8s

[mattfarina]

I can explain what's going on here and what you can do now to get the result you want.

v1.20.2-34+350770ed07a558 is a complex version. The 1.20.2 is the major.minor.patch. The -34 signifies this is a pre-release. There are numerous Kubernetes providers that are using pre-releases to signify something about their version. When they do this they don't mean it's a pre-release. Instead they are breaking out of semantic versioning for their scheme. Kubernetes uses SemVer so there is a slight mismatch. Tools designed for Kubernetes versioning sometimes have issues when someone breaks outside the semver scheme. +350770ed07a558 is build metadata and is ignored for looking up versions (per the spec).

Per the spec on pre-releases:

A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version.

A Kubernetes pre-release (e.g., 1.21.0-alpha.1) may not satisfy the API of the released version (e.g., 1.21.0). So, tools tend to ignore pre-releases when looking at ranges unless pre-release sorting is explicitly turned on. This is a common way to handle the ranges.

Because v1.20.2-34+350770ed07a558 is a pre-release that may not satisfy the API of a release version it is skipped when looking at the range >= v1.16.0,< v1.21. We are in this problematic situation because cloud providers are breaking out of semver.

A solution for this in the short term is to add -0 to the range. This tells Helm to look at pre-releases as well as stable releases. 0 is used because SemVer uses ASCII (see the spec) and 0 is the lowest ASCII character used in SemVer. It's not allowed to be the first character of a pre-release (per the spec). So, it works. A range of >= v1.16.0,< v1.21-0 will find v1.20.2-34+350770ed07a558.

[scaleoutsean]

Thanks, Matt.
The solution suggested in the other issue (to add -0) I mentioned at the top of my submission and it doesn't seem to work (with or without the 'v prefix).
I marked out that part and used v1.21-0 to try that as well, but that doesn't work either.

# helm install trident trident-operator --namespace trident --create-namespace
Error: chart requires kubeVersion: >= v1.16.0, < v1.21-0 which is incompatible with Kubernetes v1.20.2-34+c6851e88267786

$ cat Chart.yaml  | grep kubeVersion
# kubeVersion: ">= 1.16.0, < 2.0.0-0"
kubeVersion: ">= v1.16.0, < v1.21-0"
# kubeVersion: ">= 1.16.0, < 1.21.0-0"

# helm version
version.BuildInfo{Version:"v3.5.2", GitCommit:"167aac70832d3a384f65f9745335e9fb40169dc2", GitTreeState:"dirty", GoVersion:"go1.15.7"}

I used snap install microk8s --classic --channel=1.20/edge to get that version. I did not enable helm3 in microk8s (because it's v3.0.2), instead I installed kubectl v1.20-2 and helm 3.5.2.

# kubectl version
Client Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.2", GitCommit:"faecb196815e248d3ecfb03c680a4507229c2a56", GitTreeState:"clean", BuildDate:"2021-01-13T13:28:09Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/arm64"}
Server Version: version.Info{Major:"1", Minor:"20+", GitVersion:"v1.20.2-34+c6851e88267786", GitCommit:"c6851e8826778654488e9de69b468e1f408f10a6", GitTreeState:"clean", BuildDate:"2021-02-16T16:05:45Z", GoVersion:"go1.15.8", Compiler:"gc", Platform:"linux/arm64"}

I don't mind to mark out kubeVersion, it doesn't bother me much, and I saw there's a proposal to add the ability to ignore this kubeVersion (in #8986) - that'd work for me too. I opened this issue mostly for the reference of others who come across this problem.
If the version info affecting me isn't SemVer compliant and that's a requirement for Helm, we can close this issue.

[mattfarina]

I have verified this bug.

[mattfarina]

@scaleoutsean I figured out what's going on and what you can do in the short term.

The simple solution is to use:

kubeVersion: ">= v1.16.0-0, < v1.21-0"

What's going on under the hood is that the and condition evaluates the version against each condition. The first one was not looking for pre-releases so it was rejected immediately. Each of the conditions in the set needs to be looking for pre-releases right now.

[scaleoutsean]

That's funny - who would have thought! Great find. We can close this issue as far as I am concerned, thanks!