Helm: Kubeapps doesn't consider the default values set from the chart

[dud225]

Describe the bug
When using Kubeapps to manage a Helm deployment that has been previously installed outside of it and for which only a subset of the values were specified (relying on the default values set from the chart for the others), Kubeapps only takes into consideration the values set at installation time.

To Reproduce

1. Install a Helm release from the command line:

helm --namespace test  install test . --set ingress.tls.enabled=false

2. Perform an upgrade from Kubeapps
3. If the chart has a complete schema requiring all the values to be set, Kubeapps complains that the schema validation fails because it doesn't consider the default values set from the chart

Expected behavior
Kubeapps should merge the default values set from the chart with the ones set by the user.

Screenshots
Kubeapps only considers the values set from the user:

If the chart schema enforces the presence of all the values, then Kubeapps complains that the values aren't valid:

Versions:

• Version: 2.4.5
• Kubernetes version: 1.24
• Package version: Helm version 3.8.0

[absoludity]

From slack: yes,

Kubeapps should not be dependent on the format used for the values.yaml of an initial deploy (ie. we actually present and so submit the full values.yaml file). For example, in this case, if the validation issue is appearing during a subsequent upgrade of the 3rd party release/package in kubeapps, I assume we could (and should) be merging the values.yaml of the release with the previous installation values (I thought we were). Or maybe the issue is earlier? Anyway, if you have a chance, can you please open an issue and clear steps to reproduce, identifying where the problem appears etc. I think that'd be helpful both for discussion as well as helping whoever gets to implement it 🙂 Thanks!

Thanks for the extra information. Yes, I agree - the Kubeapps validation of the user values should take into account the default values that are not set, rather than relying on the (Kubeapps UI only) default values all being set in the deploy explicitly.

[dud225]

I've just upgraded to the latest version:

• App Version: 2.6.0
• Package Version: 11.0.1

but I'm still experiencing this issue.

[antgamdia]

Mmm, will check during the next iteration. I thought it got solved :S
Thanks for the update!

[antgamdia]

I've been trying to reproduce the issue, but I haven't been able to in charts whose schemas do not use any required field.

As you mentioned, "If the chart schema enforces the presence of all the values, then Kubeapps complains that the values aren't valid" I assume the problem happens when hitting the backend. As we are just passing a subset of the values, Helm is going to complain about the values being given (as they lack some of the required ones).

I don't see any quick-win solution here, unfortunately. I mean, now we display both the deployed/pkg default values, you could just revert those changes you want back manually, like:

Can you think of any other alternative?

[dud225]

On the charts I maintain I'm used to write an exhaustive schema mentioning all the values and, since a default value will always be provided by the chart, to mark them all as required. The benefit of this policy is to prevent the user from setting invalid Helm values, stemming from a typo for example.

We don't have an exclusive Kubeapps-centric usage for deploying a Helm chart as you seem to have in mind, on some cases the deployment may be sparked off Helm CLI and then managed from Kubeapps.
As a concrete example, the CI that we have implemented deploys on-demand a development version of our product remotely through Helm CLI. In this case our main focus is to tweak the Helm value governing the container image tag, as a consequence the rest of the values aren't set since the default values fits. But after the new version has undergo some tests, some problems may be found and the developer may want to perform minor changes to the deployment from Kubeapps as it is much more convenient.

So I think this issue is quite relevant for people having a restricted Helm schema and mixing Kubeapps and third-party mechanisms. I expect Kubeapps to behave similarly than Helm : it should merge the default values set from the chart with the ones provided by the user and not expect the user to always specify the comprehensive Helm values.

[absoludity]

In addition to expecting Kubeapps to behave similar to Helm regarding the validation of values passed during install, we may also want to update Kubeapps to behave similar to Helm regarding the values stored in the release on install:

• As mentioned above, Helm stores just the values provided by the user with the release,
• Kubeapps, on the other hand, stores the complete values.yaml regardless of whether the user even set one option.

We may instead want to ensure that Kubeapps passes to Helm just the values set by the user, so it behaves in the same way later (ie. helm assumes values have been set explicitly by user if included, which affects changing values on upgrade). In the past we couldn't do this as it would have meant that the user doesn't see all the other knobs in the values on upgrade (as per the screenshot above where the chart was deployed by Helm first), but that's also solveable I think? Anyway, just food for thought.