The usual way app versioning in Helm works is, the chart has a value that represents which image tag the chart should install.  That tag in turn typically maps to the application version.  This doesn’t have to be true, so if a variation of it works better for you when writing your charts, feel free to use it, but for charts made publicly available, it’s generally considered a best practice and almost all of them work that way.

--

--

Its a lot to unpack, but in https://github.com/pnnl-miscscripts/miscscripts there are scripts to:
1. automatically build containers with newest versions of dependencies
2. apply a new version number only if the fingerprint of the software and its dependencies inside the container changes
3. push the updated images only when a new one exists.

Then it does the same for charts that point to the containers.

It essentially creates a repository that keeps everything up to date and doesn't cause spurious updates when unneeded.

It probably needs some work to be really generic. If someone were up for the challenge, that could benefit a lot of folks I think. Probably needs its own project. Currently I think its one of the biggest unsolved issues in the Cloud Native landscape. I'd be happy to contribute to such a project if there is interest in forming one.

Thanks,
Kevin

________________________________________
From: cncf-helm@... <cncf-helm@...> on behalf of Matt Farina <matt@...>
Sent: Monday, May 4, 2020 1:01 PM
To: cncf-helm@...
Subject: Re: [cncf-helm] Helm versioning and CI/CD

Berin,

I am not entirely sure of your workflow so these are just ideas and thoughts in the area.

First, appVersion is optional. You do not need to use it if you don't want to.

Second, if you are using the `helm package` command there are flags to pass in the version and appVersion.

Third, it is possible to alter things in CI. I was reminded of an example Antoine Legrand put together a few years ago. You can find it at https://gitlab.com/ant31/cookieapp/-/blob/master/.gitlab-ci.yml.<https://gitlab.com/ant31/cookieapp/-/blob/master/.gitlab-ci.yml>

The neat thing about the 3rd example is you can have a tag or even get a hash for a container image and then use that in the new chart version.

Does any of this help?

- Matt Farina

On Mon, May 4, 2020, at 1:17 PM, Loritsch, Berin wrote:
I'm in the process of writing up my recommendations for how to integrate Helm into our build and deployment infrastructure. I have a few questions that I need to understand better. The most important one has to do with how versions are intended to work with Helm.

There are two versions to worry about in any given helm file:

* Chart Version {{.Chart.version}}
* Application Version {{.Chart.appVersion}}

The way I understand it, Helm charts deal with _how_ something is deployed, and the container(s) itself deals with _what_ is deployed.

In a shop where we do continuous integration/continuous deployment we need to come up with the policies for how we manage versions. For example, we have the policy that containers are built and tagged based on the code branch or tag we are building from.

Since the chart has two version numbers embedded inside, I was wondering if there are command-line arguments to override any value. The chart itself is not going to change unless we find a defect in it. It would work with our CI/CD infrastructure if we overrode the .Chart.appVersion with the branch name when we do the full build.

If that is the case, we can build our chart as if it is production, and simply override versions when deploying specific versions of an application.

--
Berin Loritsch

Systems Integration Lead

[https://lh5.googleusercontent.com/F8VCu684Vc8-wD3bTezZ6MmgbGlabJADIpQVkdjrivp_Ey7jaQtylzhE3JxCzYYUXubtuukcibd98w8Q5PXvhnpvvg3uk_jZcrBOuXY4UItaHzhl6VusEmvfCQ3Rfdz7OeLhHOU3]<https://protect2.fireeye.com/v1/url?k=65b239c5-3907067c-65b213d0-0cc47adc5fce-fd48b812c6dd0008&q=1&e=9178ae48-7532-45cb-b0d2-c00df08d0862&u=http%3A%2F%2Fwww.novetta.com%2F>

7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@...<mailto:bloritsch@...>

Office (703) 735-6281

Mobile (571) 215-7708

Yeah. versioning is always quite complicated. Distro's have had a lot more time to figure it out. If you look at the way distro's typically version things, you see something like:

mysql-5.5.50-2.el6.x86_64.rpm

The software itself has a version 5.5.50 and the packaging is a sub number off of that. '2'. What this means, is the packaging source version information can be dropped except for a release number simplifying some things.

I've been following this model for the containers I build. A container is not just the software in question, its the software + all of its dependencies + its packaging.

So, say on 01/01/2020 I build a container using Dockerfile:
FROM centos:centos7
yum install mysql-5.5.50-2

Then I build it now. The container could have all sorts of different versions of software installed. glibc for example may be significantly newer while everything else stays the same. It still is a new container and should be upgraded to.

So I fingerprint everything that goes into the container on change, and then automatically bump up the revision number if either the Dockerfile, or the Dependencies change. Ideally, the version number without the revision of the software is automatically fetchable and used in the version number as well. When done, you get a stream of images pop out like:
image: mysql-5.5.50-1
image: mysql-5.5.50-2
image: mysql-5.5.50-3
image: mysql-5.5.51-1
image: mysql-5.5.50-2
etc.

Helm charts don't really fit this model very well. You have two version numbers available. a semver Version field, and a not semver appVersion field. Users expect appVersion to somewhat fit the software being installed. A chart could have multiple container images, for example, mysql-exporter. I still use the image version above for the appVersion as its probably the closest to the users definition of appVersion. Mysql version.

For version, thats where things get ugly and I don't have it entirely flushed out. I think the algorithm is something like:
The source Version: in the chart is used as one of the inputs but isn't used for the final package directly.
The final version is kind of like a revision in a container/rpm as well as the source version. Since there is no revision in semver, I used the last value as that number.
so, X.Y.Revision
If appVersion or any of the chart dependencies, their images, or the source's Version: change, Revision is automatically incremented by one.
Ideally X.Y I think still come from the sources Version. But I'm not totally sure about that mapping. There may be dependency changes that lead to X.Y changing as well. I haven't gotten to the point of determining what the right thing to do there is.

This means releases of the chart could look like:
SourceVersion, PackageVersion, apiVersion
0.1.0 0.1.0 5.5.50-1
0.1.0 0.1.1 5.5.50-2
0.1.0 0.1.2 5.5.50-3
0.1.0 0.1.3 5.5.51-1
0.1.1 0.1.4 5.5.51-1
0.2.0 0.2.0 5.5.51-1
0.2.0 0.2.1 5.5.51-2

Helm upgrade then always does the right thing, and every version is installable.

Pretty complicated stuff. Not sure how helpful that info is, but maybe helps to explain the reasoning for the logic in that repo.

Thanks,
Kevin

________________________________________
From: cncf-helm@... <cncf-helm@...> on behalf of Loritsch, Berin <bloritsch@...>
Sent: Monday, May 4, 2020 1:22 PM
To: Matt Farina
Cc: cncf-helm@...
Subject: Re: [cncf-helm] Helm versioning and CI/CD

It does help. The main thing I'm looking for is to wrap my head around the thinking into how versioning was designed to work with helm. It's a big difference between saying "yeah that's a thing that can be done" and understanding what the ramifications of my choices are.

That being said, there are some things I want to change in the sample charts I created. I'll try to derive some inspiration from the CI definition you provided.

On Mon, May 4, 2020 at 4:02 PM Matt Farina <matt@...<mailto:matt@...>> wrote:
Berin,

I am not entirely sure of your workflow so these are just ideas and thoughts in the area.

First, appVersion is optional. You do not need to use it if you don't want to.

Second, if you are using the `helm package` command there are flags to pass in the version and appVersion.

Third, it is possible to alter things in CI. I was reminded of an example Antoine Legrand put together a few years ago. You can find it at https://gitlab.com/ant31/cookieapp/-/blob/master/.gitlab-ci.yml.<https://gitlab.com/ant31/cookieapp/-/blob/master/.gitlab-ci.yml>

The neat thing about the 3rd example is you can have a tag or even get a hash for a container image and then use that in the new chart version.

Does any of this help?

- Matt Farina

On Mon, May 4, 2020, at 1:17 PM, Loritsch, Berin wrote:
I'm in the process of writing up my recommendations for how to integrate Helm into our build and deployment infrastructure. I have a few questions that I need to understand better. The most important one has to do with how versions are intended to work with Helm.

There are two versions to worry about in any given helm file:

* Chart Version {{.Chart.version}}
* Application Version {{.Chart.appVersion}}

The way I understand it, Helm charts deal with _how_ something is deployed, and the container(s) itself deals with _what_ is deployed.

In a shop where we do continuous integration/continuous deployment we need to come up with the policies for how we manage versions. For example, we have the policy that containers are built and tagged based on the code branch or tag we are building from.

Since the chart has two version numbers embedded inside, I was wondering if there are command-line arguments to override any value. The chart itself is not going to change unless we find a defect in it. It would work with our CI/CD infrastructure if we overrode the .Chart.appVersion with the branch name when we do the full build.

If that is the case, we can build our chart as if it is production, and simply override versions when deploying specific versions of an application.

--
Berin Loritsch

Systems Integration Lead

[https://lh5.googleusercontent.com/F8VCu684Vc8-wD3bTezZ6MmgbGlabJADIpQVkdjrivp_Ey7jaQtylzhE3JxCzYYUXubtuukcibd98w8Q5PXvhnpvvg3uk_jZcrBOuXY4UItaHzhl6VusEmvfCQ3Rfdz7OeLhHOU3]<https://protect2.fireeye.com/v1/url?k=639d92c5-3f28ac0a-639db8d0-0cc47adc5e60-0b527a8768ddea91&q=1&e=97be222e-12bc-4e86-9d05-fa292b3a5f41&u=http%3A%2F%2Fwww.novetta.com%2F>

7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@...<mailto:bloritsch@...>

Office (703) 735-6281

Mobile (571) 215-7708




--
Berin Loritsch

Systems Integration Lead

[https://lh5.googleusercontent.com/F8VCu684Vc8-wD3bTezZ6MmgbGlabJADIpQVkdjrivp_Ey7jaQtylzhE3JxCzYYUXubtuukcibd98w8Q5PXvhnpvvg3uk_jZcrBOuXY4UItaHzhl6VusEmvfCQ3Rfdz7OeLhHOU3]<https://protect2.fireeye.com/v1/url?k=fd3d9284-a188ac4b-fd3db891-0cc47adc5e60-d7dc2411bd30ba42&q=1&e=97be222e-12bc-4e86-9d05-fa292b3a5f41&u=http%3A%2F%2Fwww.novetta.com%2F>

7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@...<mailto:bloritsch@...>

Office (703) 735-6281

Mobile (571) 215-7708