setting appVersion in chart.yaml and allowing tag in values.yaml leads to "inconsitent" state

[christopheblin]

Which chart:
I think this problem is common to lots of charts, but I'll take postgres as an example

Describe the bug
helm list will report an APP VERSION that does NOT match the version of the deployed app if you change the tag in the values.yaml file when you use the chart

To Reproduce
In chart.yaml (https://github.com/bitnami/charts/blob/master/bitnami/postgresql/Chart.yaml), appVersion is set to `appVersion: 11.12.0``

In values.yaml (https://github.com/bitnami/charts/blob/master/bitnami/postgresql/values.yaml), the image tag can be set to something else (at the moment, it is tag: 11.12.0-debian-10-r44)

If I change the tag to something else (like 12.7.0-debian-10-r68), it will correctly deploy the 12.7.0 (actually, I did not test it for real, but you get the point : I can set the deployed app to another version)

Now, if I do helm list, I would still see APP VERSION = 11.12.0

Expected behavior
I am not sure what is the best practice here or if it is really a bug...

From my POV, appVersion should not be set if you allow the tag to be changed (or should be documented in the values.yaml that changing the tag will lead to inconsistent behavior)

Version of Helm and Kubernetes:

Irrelevant

Additional context

N/A

[alvneiayu]

hi @christopheblin

This is a really interesting topic. In my opinion, I think that this is a Helm limitation. "Helm list" will get the information from the Chart.yaml but the values that we are going to use to generate the template are in values.yaml. The metadata information is store inside the Chart.yaml and in case that you decided to modify manually a tag inside the values.yaml, you must to update the Chart.yaml to align the metadata information. I took a look another charts like cert-manager (jet-pack) and you will see the same problem.

In my opinion, this is something that the developers must take into a account always. If you made a change, you need to take into account to modify the metadata information related to the project (appVersion, semver, etc). Maybe one solution is to include something in the README o values.yaml (a comment) to remember this to the developers. Include a tag limitation, I think that it is not the best way. We are open to receive PRs and we will really happy to review it.

Thanks a lot for notifying this to us and thanks a lot for your time

Álvaro

[christopheblin]

I found helm/helm#3555 that seems to match this problem

There is quite a long and heated debate there with refused PR and other stuff like sub-issues and duplicates

At the end, it seems helm developers consider it is the responsibility of package managers to put the correct appVersion...

However, because it is now very common to use charts from external repos, we CAN NOT change the Chart.yaml (and so we cannot change the appVersion easily)

And so, here is how it looks like (I do not have the exact commands anymore, this is from the top of my head)

$> helm repo add bitnami https://charts.bitnami.com/bitnami
...
$> helm upgrade myrelease --install --set image.tag 12.7.0-debian-10-r68 bitnami/postgres
...
$> helm list
NAME            ...     CHART   APP VERSION
myrealease      ...     10.9.1  11.12.0

As you can see, as a "simple" user, I can not control what is displayed here BUT this is clearly very misleading

Do you have an idea how I can change the image.tag and the appVersion when using the bitnami repo ?

I'll try to see if helm developers can consider something like helm upgrade myrelease --install --set image.tag 12.7.0-debian-10-r68 --app-version 12.7.0 bitnami/postgres

[Frontrider]

Your pipeline can't even publish a fresh version of your chart from a new release, someone must go in and manually edit 1 string in a file that you'd already have as a parameter for the pipe (like we're in the 90s). You can automatically release a new version to any other package manager except helm.
Or hack the system with the automatic file editing solution of your choice.

It is fine if it's limited exclusively to local charts so you can change it before you publish, I can see it be an issue with remote charts.

[javsalgar]

I found helm/helm#3555 that seems to match this problem

There is quite a long and heated debate there with refused PR and other stuff like sub-issues and duplicates

At the end, it seems helm developers consider it is the responsibility of package managers to put the correct appVersion...

However, because it is now very common to use charts from external repos, we CAN NOT change the Chart.yaml (and so we cannot change the appVersion easily)

And so, here is how it looks like (I do not have the exact commands anymore, this is from the top of my head)

$> helm repo add bitnami https://charts.bitnami.com/bitnami
...
$> helm upgrade myrelease --install --set image.tag 12.7.0-debian-10-r68 bitnami/postgres
...
$> helm list
NAME            ...     CHART   APP VERSION
myrealease      ...     10.9.1  11.12.0

As you can see, as a "simple" user, I can not control what is displayed here BUT this is clearly very misleading

Do you have an idea how I can change the image.tag and the appVersion when using the bitnami repo ?

I'll try to see if helm developers can consider something like helm upgrade myrelease --install --set image.tag 12.7.0-debian-10-r68 --app-version 12.7.0 bitnami/postgres

Hi,

I agree that it can be misleading, especially for charts like PostgreSQL where we support different branches in the chart. Right now, it seems that the only option would be to have one PostgreSQL chart per branch, which could be a nightmare in terms of maintainability. I agree that helm should allow an easy way to modify appVersion or simply remove it completely.

In terms of workaround, I believe that the only option would be fetching, changing Chart.yaml and deploy the chart. I can see how painful that approach could become. Out of curiosity, are you using the output of helm ls in some sort of UI? Maybe, as an alternative, you could try getting the image tag from the deployed charts and show that instead.

[christopheblin]

I found helm/helm#8194 where the helm maintainers wants lots of bureaucracy around an HIP to have this feature implemented because they consider it has major impacts on the impl

=> I do not have the time to go through this unfortunately (somehow, it would have more weight if package maintainers like you and other big open source projects make the call, but I also know that you have more important things to do like updating for real the packages in newer versions ...)

we work around with sed for local charts

#overwrite appVersion of Chart.yaml
- 'sed -i -E "s/^appVersion: (.*)/appVersion: ${CI_COMMIT_SHORT_SHA}/" k8s/charts/app/Chart.yaml'
- helm upgrade $RELEASE --install  -n ${NAMESPACE} -f k8s/staging.yaml k8s/charts/app

For remote charts, like you said

In terms of workaround, I believe that the only option would be fetching, changing Chart.yaml and deploy the chart. I can see how painful that approach could become.

It is very painful because basically what you want is to extract appVersion from the image.tag in values.yaml file (you do not want it as a param of your CI/CD ...)

the command to do that is helm pull repo/chart --untar followed by the sed

Out of curiosity, are you using the output of helm ls in some sort of UI? Maybe, as an alternative, you could try getting the image tag from the deployed charts and show that instead.

devs are used to helm list to have an overview of what components are inside the current namespace

so, I try to educate them to use some kubectl commands like kubectl get deployment xxx -o jsonpath=xxx

however :

1. it is not always a deployment (could be a statefuset / etc...) so there are multiple commands to remember
2. it is not the same command when the pod contains multiple containers
3. the main reason : it is a lot more harder than helm list

I think you can close the issue unless you want to do something about the situation (like adding a comment in all values.yaml or something in the doc or ...)

like you said, it is mostly annoying for charts that are MEANT to support multiple versions of the target app

for these chart, you can go to the "extreme" and stop populating "app version" (or populating with "see container.image in deployment")

you may have some users unhappy (i.e users who do not change the tag are currently happy because they have the correct information in helm list)

and you will have some users happy (like me :) ) because they do not have to explain to dev why helm list does not display correct infrmation

[javsalgar]

Hi,

I will forward this to the docs team and maybe we can write a clarification in our documentation. cc @vikram-bitnami

[github-actions]

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

[github-actions]

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.