Date   

Feedback on proposal

jorgecarleitao@...
 

Hi,

I am writing to formalize a proposal to extend Helm 3 in a backward compatible manner to allow passing derived values to subcharts without exposing them in `values.yaml`. I wrote this an issue on github, 8576, and opened a PR with a minimal implementation the proposal, 8580. I consider this a major feature, and as such I am opening this topic here to gather your thoughts.

I am willing to drive this, but I will need some guidance.

Best,
Jorge


Re: stepping down

Martin Hickey
 

Hi Michelle,
 
It was great to have had a chance to work with you. All the best in your new adventures.

Regards,
Martin
 
 

----- Original message -----
From: "minooral via lists.cncf.io" <minooral=microsoft.com@...>
Sent by: cncf-helm@...
To: cncf-helm@...
Cc:
Subject: [EXTERNAL] [cncf-helm] stepping down
Date: Wed, Jul 8, 2020 12:35 AM
 

[Edited Message Follows]

Hey Helmettes,

It's been a pleasure being a core maintainer on the Helm project since it's initial release Helm Classic (v1) in 2015 and probably the coolest experience of my career. I am officially stepping down as core maintainer to focus on other responsibilities. I've learned a lot from everyone involved and appreciate having had the opportunity to work with you all.
https://github.com/helm/helm/pull/8414

--- Feel free to ignore the rest of this if you don't care for long messages but I do want to take a few minutes to give my thanks.---

Thank you Matt Butcher for giving me room and guidance to build out parts of Helm v1 and v2. I learned a lot about how to do open source and build a community, how to research and think through design decisions and iterate on them, and how to write Go from you. I will always appreciate your patience and the opportunities you encouraged me to take. I remember you asking me to compile my code on the spot and and show Bitnami (and others) what we were working on in the early days. Obviously, I don't recommend that for everyone but when you asked me do that (more than once), it helped me learn how to talk about what we were working on on the spot. I learned how to demo, give the right amount of context without prep, and it made me more confident about showing work in progress. Thanks for helping build a safe and respectful environment to work in (you and Adam both). Thank you Adam Reese for being my partner in crime, for always supporting me and having my back. I loved going through this journey with you from building a PaaS at Engine Yard to building a package manager for Kubernetes. I will never forget the times where we'd get on calls and admit to each other we were both totally lost lol. I learned a lot about how to ask the right questions and articulate problems more clearly from you. Thank you Brian Hardock for helping me think deeper about the software and tools we use. Adnan, Miguel, Sameer, Jack Francis, Brian Grant, Vic, Sebastian, Bridget, Matt Fisher, Martin. I've had a blast with you all. I know I am missing people (sorry). Super proud of this tool and community and still humbled I got the opportunity to work on it.


Cheers,

Michelle Noorali
 


stepping down

minooral@...
 
Edited

Hey Helmettes,

It's been a pleasure being a core maintainer on the Helm project since it's initial release Helm Classic (v1) in 2015 and probably the coolest experience of my career. I am officially stepping down as core maintainer to focus on other responsibilities. I've learned a lot from everyone involved and appreciate having had the opportunity to work with you all.
https://github.com/helm/helm/pull/8414

--- Feel free to ignore the rest of this if you don't care for long messages but I do want to take a few minutes to give my thanks.---

Thank you Matt Butcher for giving me room and guidance to build out parts of Helm v1 and v2. I learned a lot about how to do open source and build a community, how to research and think through design decisions and iterate on them, and how to write Go from you. I will always appreciate your patience and the opportunities you encouraged me to take. I remember you asking me to compile my code on the spot and and show Bitnami (and others) what we were working on in the early days. Obviously, I don't recommend that for everyone but when you asked me do that (more than once), it helped me learn how to talk about what we were working on on the spot. I learned how to demo, give the right amount of context without prep, and it made me more confident about showing work in progress. Thanks for helping build a safe and respectful environment to work in (you and Adam both). Thank you Adam Reese for being my partner in crime, for always supporting me and having my back. I loved going through this journey with you from building a PaaS at Engine Yard to building a package manager for Kubernetes. I will never forget the times where we'd get on calls and admit to each other we were both totally lost lol. I learned a lot about how to ask the right questions and articulate problems more clearly from you. Thank you Brian Hardock for helping me think deeper about the software and tools we use. Adnan, Miguel, Sameer, Jack Francis, Brian Grant, Vic, Sebastian, Bridget, Matt Fisher, Martin. I've had a blast with you all. I know I am missing people (sorry). Super proud of this tool and community and still humbled I got the opportunity to work on it.


Cheers,

Michelle Noorali


Re: How can we achieve automatic rollback in case of "helm upgrade" failures?

Matt Fisher <matt.fisher@...>
 

Not sure where you got the information that the atomic flag doesn’t exist in Helm 3. I just checked, and it’s been there since Helm 3.0.0, and it’s present in HEAD.



If you want to automatically roll back in case of a failure, you can use the atomic flag. I’m not aware of another feature to handle rollbacks.

1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada



From: cncf-helm@... <cncf-helm@...> on behalf of vtejaswini1 via lists.cncf.io <vtejaswini1=gmail.com@...>
Sent: Wednesday, July 1, 2020 10:00 AM
To: cncf-helm@... <cncf-helm@...>
Subject: [cncf-helm] How can we achieve automatic rollback in case of "helm upgrade" failures?
 
Hi,

Does anyone have ideas about supporting automatic rollback in terms of failures? Over slack, people recommend different sets of tools. What is the recommended approach or best feasible approach to use?

Do I need to use any helm operator or?

I also notice helm3 not supporting the atomic flag, which was created to support automatic rollback.

Thanks,
Teja


How can we achieve automatic rollback in case of "helm upgrade" failures?

@Tejaswini_Vadlamudi
 

Hi,

Does anyone have ideas about supporting automatic rollback in terms of failures? Over slack, people recommend different sets of tools. What is the recommended approach or best feasible approach to use?

Do I need to use any helm operator or?

I also notice helm3 not supporting the atomic flag, which was created to support automatic rollback.

Thanks,
Teja


Re: What is the proper way to rollback using helm, Is it using "helm rollback" or "helm upgrade olderversion"?

Paul Czarkowski <pczarkowski@...>
 

Hi Teja!

Both are completely valid option.  People generally like the rollback commands as it's rolling your kubernetes manifests back to a known good version, therefore if there was an error introduced by a change in the Helm charts themselves it would not continue that error.

However this option doesn't take into account the application itself. If there is a bug in the application or you have a backwards incompatible database schema change, then it would make sense to roll forward with a newer image and a `helm upgrade`.



From: cncf-helm@... <cncf-helm@...> on behalf of vtejaswini1@... <vtejaswini1@...>
Sent: Wednesday, July 1, 2020 8:35 AM
To: cncf-helm@... <cncf-helm@...>
Subject: [cncf-helm] What is the proper way to rollback using helm, Is it using "helm rollback" or "helm upgrade olderversion"?
 
Hi,

I was looking at downgrading software on failure. I wonder if I need to run upgrade an older version or use the "helm rollback" command.

Well, I don't have enough arguments about why I need to use "helm rollback" for rolling back software.

Does anyone know the reasons behind this support?

Thanks,
Teja


What is the proper way to rollback using helm, Is it using "helm rollback" or "helm upgrade olderversion"?

@Tejaswini_Vadlamudi
 

Hi,

I was looking at downgrading software on failure. I wonder if I need to run upgrade an older version or use the "helm rollback" command.

Well, I don't have enough arguments about why I need to use "helm rollback" for rolling back software.

Does anyone know the reasons behind this support?

Thanks,
Teja


Re: Helm for Microservices Deployments

Lei Zhang
 

Hi Berin

The answer should also depend on what's your intention to group these pieces together.

If the intention is to packaging and distributing, Paul's suggestion of two-layer charts should work. Another similar approach could be CNAB (https://cnab.io/) + charts, so CNAB could be used as the parent layer of your package. 

If the intention is to create a application definition for Kubernetes so you can declare dependencies of the components etc, then server side app model may be the solution, for example:  https://speakerdeck.com/resouer/oam-as-kubernetes-application-definition. In this case, you will have a helm chart to package a single app-config.yaml


Re: Helm for Microservices Deployments

Loritsch, Berin <bloritsch@...>
 

Out of curiosity, why wouldn't you simply have a master helm chart for the full application that declares all of the dependencies? As opposed to learning yet another tool (https://github.com/roboll/helmfile).


On Fri, Jun 26, 2020 at 2:53 PM Loritsch, Berin via lists.cncf.io <bloritsch=novetta.com@...> wrote:
The complication I have is that the customer I have has very outdated concepts for approving and managing deployments.  As a result, our devops pipeline is segregated from the production environment.  However as part of the delivery we can provide the containers and helm charts for all the pieces.  Once we get the go-ahead from the approval body we can run the "helm install" or "helm upgrade" process for the whole app.

It is our full intention to have sub-charts at least for each microservice should this archaic business process be brought into the 21st century.  However, in the interim we will need a master chart to define the entire application.  I did find a good approach for using labels to address some parts ot the problem: https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/

Thanks for the pointer to helmfile.  I will look at that to see if I can use it to manage our deployments.  We manage our dev and QA instances of the application using full DevOps.  The disconnect comes in when we have to manage an acceptance test and production instance of the application on our customer's private cloud.  Each of those environments requires some customization so we can point at managed resources without risking production problems.


On Fri, Jun 26, 2020 at 11:49 AM Paul Czarkowski <pczarkowski@...> wrote:
In my opinion at least, Ideally each microservice would have its own fully independent chart, and be deployed and managed independely by some sort of CI/CD solution that roughly resembles gitops.

If you need to share data or values between microservices, then you could look to using a library chart ( https://helm.sh/docs/topics/library_charts/ ) which you could use to define extra labels to help tie environments together (via metadata at least) and do things like set names for service discovery, create secrets with TLS certs, that kind of thing.

If you need to deploy all of the microservices as a bundle, then I would would reach up a layer to a tool like helmfile (https://github.com/roboll/helmfile) which can help you deploy and manage sets of loosely coupled helm charts.

From: cncf-helm@... <cncf-helm@...> on behalf of Loritsch, Berin <bloritsch@...>
Sent: Thursday, June 25, 2020 3:21 PM
To: cncf-helm@... <cncf-helm@...>
Subject: [cncf-helm] Helm for Microservices Deployments
 
As I dive deeper into the world of Kubernetes so that I understand what I need my charts to do, and how I intend to design the templates for my environment, I am curious how Helm ties things together.

For example, we have 30+ microservices in 7 functional areas, all for one application.  We want to handle deployments with horizontal scaling, volumes, etc.

I think the picture is crystal clear when we are talking about one service.  I.e. 1 microservice would have 1 deployment, 1 hpa, ingress instructions, a service definition, and volumes and configmaps to support it.  I look at some of the examples for larger systems, and the examples I see use labels to tie things together.

When I create a parent chart that declares all of the microservices as dependencies, does Helm inject labels on my behalf?  For example, given I am in a namespace for the environment, I want to type "helm install wicketz example/wicketzapp" and then later when I need to update it or uninstall it, I would update the "wicketz" app in that custom namespace.  Additionally, as we replace microservices we no longer need because they are now redundant with Kubernetes features, I'd like the update to remove the deployments that are no longer needed.

What's the glue that binds things together?  Is that something I have to manage myself, or be aware of as I'm writing my helm charts?  Unfortunately, too many of the examples I find are too simplistic to answer the questions I'm having now.

--
Berin Loritsch

Systems Integration Lead


7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@...

Office (703) 735-6281

Mobile (571) 215-7708



--
Berin Loritsch

Systems Integration Lead


7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@...

Office (703) 735-6281

Mobile (571) 215-7708



--
Berin Loritsch

Systems Integration Lead


7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@...

Office (703) 735-6281

Mobile (571) 215-7708


Re: Helm for Microservices Deployments

Loritsch, Berin <bloritsch@...>
 

The complication I have is that the customer I have has very outdated concepts for approving and managing deployments.  As a result, our devops pipeline is segregated from the production environment.  However as part of the delivery we can provide the containers and helm charts for all the pieces.  Once we get the go-ahead from the approval body we can run the "helm install" or "helm upgrade" process for the whole app.

It is our full intention to have sub-charts at least for each microservice should this archaic business process be brought into the 21st century.  However, in the interim we will need a master chart to define the entire application.  I did find a good approach for using labels to address some parts ot the problem: https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/

Thanks for the pointer to helmfile.  I will look at that to see if I can use it to manage our deployments.  We manage our dev and QA instances of the application using full DevOps.  The disconnect comes in when we have to manage an acceptance test and production instance of the application on our customer's private cloud.  Each of those environments requires some customization so we can point at managed resources without risking production problems.


On Fri, Jun 26, 2020 at 11:49 AM Paul Czarkowski <pczarkowski@...> wrote:
In my opinion at least, Ideally each microservice would have its own fully independent chart, and be deployed and managed independely by some sort of CI/CD solution that roughly resembles gitops.

If you need to share data or values between microservices, then you could look to using a library chart ( https://helm.sh/docs/topics/library_charts/ ) which you could use to define extra labels to help tie environments together (via metadata at least) and do things like set names for service discovery, create secrets with TLS certs, that kind of thing.

If you need to deploy all of the microservices as a bundle, then I would would reach up a layer to a tool like helmfile (https://github.com/roboll/helmfile) which can help you deploy and manage sets of loosely coupled helm charts.

From: cncf-helm@... <cncf-helm@...> on behalf of Loritsch, Berin <bloritsch@...>
Sent: Thursday, June 25, 2020 3:21 PM
To: cncf-helm@... <cncf-helm@...>
Subject: [cncf-helm] Helm for Microservices Deployments
 
As I dive deeper into the world of Kubernetes so that I understand what I need my charts to do, and how I intend to design the templates for my environment, I am curious how Helm ties things together.

For example, we have 30+ microservices in 7 functional areas, all for one application.  We want to handle deployments with horizontal scaling, volumes, etc.

I think the picture is crystal clear when we are talking about one service.  I.e. 1 microservice would have 1 deployment, 1 hpa, ingress instructions, a service definition, and volumes and configmaps to support it.  I look at some of the examples for larger systems, and the examples I see use labels to tie things together.

When I create a parent chart that declares all of the microservices as dependencies, does Helm inject labels on my behalf?  For example, given I am in a namespace for the environment, I want to type "helm install wicketz example/wicketzapp" and then later when I need to update it or uninstall it, I would update the "wicketz" app in that custom namespace.  Additionally, as we replace microservices we no longer need because they are now redundant with Kubernetes features, I'd like the update to remove the deployments that are no longer needed.

What's the glue that binds things together?  Is that something I have to manage myself, or be aware of as I'm writing my helm charts?  Unfortunately, too many of the examples I find are too simplistic to answer the questions I'm having now.

--
Berin Loritsch

Systems Integration Lead


7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@...

Office (703) 735-6281

Mobile (571) 215-7708



--
Berin Loritsch

Systems Integration Lead


7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@...

Office (703) 735-6281

Mobile (571) 215-7708


Re: Helm for Microservices Deployments

Paul Czarkowski <pczarkowski@...>
 

In my opinion at least, Ideally each microservice would have its own fully independent chart, and be deployed and managed independely by some sort of CI/CD solution that roughly resembles gitops.

If you need to share data or values between microservices, then you could look to using a library chart ( https://helm.sh/docs/topics/library_charts/ ) which you could use to define extra labels to help tie environments together (via metadata at least) and do things like set names for service discovery, create secrets with TLS certs, that kind of thing.

If you need to deploy all of the microservices as a bundle, then I would would reach up a layer to a tool like helmfile (https://github.com/roboll/helmfile) which can help you deploy and manage sets of loosely coupled helm charts.


From: cncf-helm@... <cncf-helm@...> on behalf of Loritsch, Berin <bloritsch@...>
Sent: Thursday, June 25, 2020 3:21 PM
To: cncf-helm@... <cncf-helm@...>
Subject: [cncf-helm] Helm for Microservices Deployments
 
As I dive deeper into the world of Kubernetes so that I understand what I need my charts to do, and how I intend to design the templates for my environment, I am curious how Helm ties things together.

For example, we have 30+ microservices in 7 functional areas, all for one application.  We want to handle deployments with horizontal scaling, volumes, etc.

I think the picture is crystal clear when we are talking about one service.  I.e. 1 microservice would have 1 deployment, 1 hpa, ingress instructions, a service definition, and volumes and configmaps to support it.  I look at some of the examples for larger systems, and the examples I see use labels to tie things together.

When I create a parent chart that declares all of the microservices as dependencies, does Helm inject labels on my behalf?  For example, given I am in a namespace for the environment, I want to type "helm install wicketz example/wicketzapp" and then later when I need to update it or uninstall it, I would update the "wicketz" app in that custom namespace.  Additionally, as we replace microservices we no longer need because they are now redundant with Kubernetes features, I'd like the update to remove the deployments that are no longer needed.

What's the glue that binds things together?  Is that something I have to manage myself, or be aware of as I'm writing my helm charts?  Unfortunately, too many of the examples I find are too simplistic to answer the questions I'm having now.

--
Berin Loritsch

Systems Integration Lead


7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@...

Office (703) 735-6281

Mobile (571) 215-7708


Re: Announcing ChartCenter, the free central repository for Helm charts

Jimmy Zelinskie <jimmyzelinskie@...>
 

Congratulations on the launch, Rimas!


On Fri, Jun 26, 2020 at 9:49 AM Rimas <rmocius@...> wrote:

Helm charts make your Kubernetes deployments as easy as possible and today I’m happy to announce: ChartCenter, the free central repository for Helm charts.

 chartcenter.io is an immutable, safe, and free central repository that includes high-level vulnerability scanning, robust metadata, dependency graphs and more! Use our superior search to uncover a list of matches based on name, description, and keywords. You can also add your own charts and repositories.

You can use it as a single helm repo to access many charts from different helm repos.

Take a look to my blog for more details https://rimusz.net/chartcenter 2


Announcing ChartCenter, the free central repository for Helm charts

Rimas
 

Helm charts make your Kubernetes deployments as easy as possible and today I’m happy to announce: ChartCenter, the free central repository for Helm charts.

 chartcenter.io is an immutable, safe, and free central repository that includes high-level vulnerability scanning, robust metadata, dependency graphs and more! Use our superior search to uncover a list of matches based on name, description, and keywords. You can also add your own charts and repositories.

You can use it as a single helm repo to access many charts from different helm repos.

Take a look to my blog for more details https://rimusz.net/chartcenter 2


Helm for Microservices Deployments

Loritsch, Berin <bloritsch@...>
 

As I dive deeper into the world of Kubernetes so that I understand what I need my charts to do, and how I intend to design the templates for my environment, I am curious how Helm ties things together.

For example, we have 30+ microservices in 7 functional areas, all for one application.  We want to handle deployments with horizontal scaling, volumes, etc.

I think the picture is crystal clear when we are talking about one service.  I.e. 1 microservice would have 1 deployment, 1 hpa, ingress instructions, a service definition, and volumes and configmaps to support it.  I look at some of the examples for larger systems, and the examples I see use labels to tie things together.

When I create a parent chart that declares all of the microservices as dependencies, does Helm inject labels on my behalf?  For example, given I am in a namespace for the environment, I want to type "helm install wicketz example/wicketzapp" and then later when I need to update it or uninstall it, I would update the "wicketz" app in that custom namespace.  Additionally, as we replace microservices we no longer need because they are now redundant with Kubernetes features, I'd like the update to remove the deployments that are no longer needed.

What's the glue that binds things together?  Is that something I have to manage myself, or be aware of as I'm writing my helm charts?  Unfortunately, too many of the examples I find are too simplistic to answer the questions I'm having now.

--
Berin Loritsch

Systems Integration Lead


7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@...

Office (703) 735-6281

Mobile (571) 215-7708


Helm using the same template for python and java springboot

kumaryoa@...
 

Hi,

I would like to know can we use the same helm chart template for python and java sprinboot applications. I have my git repository name(sample) is common for these both the codes. But it uses different memory configs and envrionment variables. Please suggest me how can i deploy both the code using single helm chart template.


Re: Share common configmap / data

Paul Czarkowski <pczarkowski@...>
 

Hey,

Helm Charts themselves can't access contents of a configmap.  You could either set these values as `global` values and make them available across all charts (if using chart dependencies/child charts - https://helm.sh/docs/chart_template_guide/subcharts_and_globals/ )  or you can create the configmap and then if the other charts mount that configmap as env vars or a file and load them in to each deployment that way.

On Sat, May 9, 2020 at 11:51 AM <frnd4u.ashok@...> wrote:
I'm newbie to helm and trying to understand and develop helm charts for my organization, so pardon my knowledge on the subject.This is my idea of sharing a common library configmap to access across multiple charts.
I want to identify account number and other details of AWS deployment, so I can set some values accordingly.
Is this correct? I can pass in .Values.account appropriate value and how do I go about accessing in this example account_number
apiVersion: v1
kind: ConfigMap
metadata:
name: aws
data:
account_number:
{{- if eq .Values.account "dev" }}
{{- printf "YX3XX2YX1YX6"}}
{{- else if eq .Values.account "stg" }}
{{- printf "X48XY438611X"}}
{{- else if eq .Values.account "prd" }}
{{- printf "Y83Y23X888X1"}}
{{- end }}


Re: local filesystem chart dependencies

Paul Czarkowski <pczarkowski@...>
 

Hi Marvin,

I believe the dependency entry should as follows ( `..` instead of `.` since the game-tracker chart is in the same parent directory as `teamdb-ui`:

```
dependencies:
  - name: game-tracker
    version: 0.1.0
    repository: "file://../game-tracker"
```

On Mon, May 11, 2020 at 5:36 AM Just Marvin <marvin.the.cynical.robot@...> wrote:
Hi,

    I've got two charts on my filesystem - which are not uploaded yet to any repo. They are both located in the same directory.

[zaphod@oc3027208274 helm]$ ls
game-tracker  teamdb-ui


Snippet from Charts.yaml of "teamdb-ui":

dependencies:
  - name: game-tracker
    version: 0.1.0
    repository: "file://./game-tracker"


    However, when I do a "dependency list", I get this status:

zaphod@oc3027208274 helm]$ helm dependency list teamdb-ui
NAME         VERSION REPOSITORY           STATUS
game-tracker 0.1.0   file://./game-tracker missing

    I have tried various syntaxes - file://. and other variants as well. Its also not clear if the dependency needs to be to the chart version or the app version, but I have tried with both. How do I get this working?

Regards,
Marvin


local filesystem chart dependencies

Just Marvin
 

Hi,

    I've got two charts on my filesystem - which are not uploaded yet to any repo. They are both located in the same directory.

[zaphod@oc3027208274 helm]$ ls
game-tracker  teamdb-ui


Snippet from Charts.yaml of "teamdb-ui":

dependencies:
  - name: game-tracker
    version: 0.1.0
    repository: "file://./game-tracker"


    However, when I do a "dependency list", I get this status:

zaphod@oc3027208274 helm]$ helm dependency list teamdb-ui
NAME         VERSION REPOSITORY           STATUS
game-tracker 0.1.0   file://./game-tracker missing

    I have tried various syntaxes - file://. and other variants as well. Its also not clear if the dependency needs to be to the chart version or the app version, but I have tried with both. How do I get this working?

Regards,
Marvin


Share common configmap / data

frnd4u.ashok@...
 

I'm newbie to helm and trying to understand and develop helm charts for my organization, so pardon my knowledge on the subject.This is my idea of sharing a common library configmap to access across multiple charts.
I want to identify account number and other details of AWS deployment, so I can set some values accordingly.
Is this correct? I can pass in .Values.account appropriate value and how do I go about accessing in this example account_number
apiVersion: v1
kind: ConfigMap
metadata:
name: aws
data:
account_number:
{{- if eq .Values.account "dev" }}
{{- printf "YX3XX2YX1YX6"}}
{{- else if eq .Values.account "stg" }}
{{- printf "X48XY438611X"}}
{{- else if eq .Values.account "prd" }}
{{- printf "Y83Y23X888X1"}}
{{- end }}


Re: Helm versioning and CI/CD

Fox, Kevin M <Kevin.Fox@...>
 

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@lists.cncf.io <cncf-helm@lists.cncf.io> on behalf of Loritsch, Berin <bloritsch@novetta.com>
Sent: Monday, May 4, 2020 1:22 PM
To: Matt Farina
Cc: cncf-helm@lists.cncf.io
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@mattfarina.com<mailto:matt@mattfarina.com>> 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@novetta.com<mailto:bloritsch@novetta.com>

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@novetta.com<mailto:bloritsch@novetta.com>

Office (703) 735-6281

Mobile (571) 215-7708

121 - 140 of 448