Charts: [stable/traefik] Can not install with helm

[jumasa]

Hi all,

stable/traefik installation with helm does not seem to work. I did perform the following steps:

helm repo list
NAME    URL                                             
stable  https://kubernetes-charts.storage.googleapis.com
local   http://127.0.0.1:8879/charts 

$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Skip local chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈ Happy Helming!⎈

$ helm search |grep traefik
stable/traefik                  1.2.1-a A Traefik based Kubernetes ingress controller w...

$ helm install stable/traefik 
Error: file "stable/traefik" not found

$ helm version
Client: &version.Version{SemVer:"v2.4.1", GitCommit:"46d9ea82e2c925186e1fc620a8320ce1314cbb02", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.4.1", GitCommit:"46d9ea82e2c925186e1fc620a8320ce1314cbb02", GitTreeState:"clean"}

I am able to install other charts like mysql.

Did I miss anything?

Thanks!

[krancour]

I also had this problem, but _only_ after upgrading my Helm to 2.4.1. Prior to that, I was unable to reproduce.

[technosophos]

See also https://github.com/kubernetes/helm/pull/2408

The bottom line is that the version number on this chart is, according to the SemVer spec "unstable", and so it will not be automatically selected. #2407 displays a workaround, and #2408 adds a --devel flag like Homebrew has.

[krancour]

Ok... that's my fault. I'll see if I can get that fixed. What I was after when I originally authored the traefik chart was a way to keep it's semver in lock step with the version of traefik the chart used, then use an extension to indicate iterations of the chart itself for a given version of traefik. I think I got the extension wrong? I'll try and fix this on the chart end if I can.

[cknowles]

According to semver 2 it's a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version.

[cknowles]

A slightly different issue using --wait and Traefk here but not sure if it's Traefik specific yet.

[krancour]

@c-knowles

According to semver 2 it's a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version.

I had read through that as well when contemplating how to fix this. But then I read this:

Build metadata SHOULD be ignored when determining version precedence.

That would imply that 1.2.3+b isn't inherently considered newer than 1.2.3+a. I'm not clear yet on whether or not that matters to Helm. e.g. If you have deployed 1.2.3+a and you helm upgrade, will Helm understand that 1.2.3+b is newer? cc @technosophos @michelleN @adamreese?

At any rate, it's probably better than what we're doing currently. Any further thoughts?

[cknowles]

Ah that's interesting. Then it would be useful to know the general direction of Helm in this regard. I agree that update is probably better but no idea which one Helm will treat as the newer one so better to try it out I suppose.

[krancour]

Then it would be useful to know the general direction of Helm in this regard.

I agree there's a broader / very general question buried in here:

If a chart provides (by default) a certain, specific version of a piece of software, how, in general, are charts (intended) to be versioned independently of the underlying software in such a way that the specific version of the underlying software that a user is installing remains transparent?

I haven't observed any existing convention that addresses this.

[adamreese]

Helm does not consider chart version when performing an upgrade. You are upgrading the release which can be an older version, the same version with different configuration, or just a newer chart version. ( not sure if that answered the question )

[krancour]

@adamreese, it does. Thank you.

I think then, based on this, for this chart, we can simply move from using a - to separate Traefik's semver from build info (chart version) to using a + for the same purpose.

[krancour]

As it turns out, chart.yaml supports an appVersion field that, prior to now, I was unaware of. (I can't believe I didn't know this!!) See #1082. Starting with version 1.3.0, the version will refer strictly to the revision of the chart, while the appVersion field will reference the revision of the software provided.