When a chart has only one extra custom values.yaml, it is implicitly used without telling users

[rophy]

Describe the bug

Feature #5692 implemented support for multiple custom values.
The feature made some assumptions on how the custom values should be presented and selected, which has some logic flaws:

1. If a chart has only 1 values.yaml (the default one), it is used without the selection drop down.
2. If a chart has only default values.yaml + 1 custom, say, values-demo.yaml, values-demo is used without the selection drop down.
3. If a chart has more than 2 values.yaml, one of the cusotomvalues is selected, and selection drop down is displayed.

The flaw is on case (2). In such case, the UI is presented as if the values is the default one, i.e. the UI looks exactly like (1), but with a customized values.

• User has no way to know that this is actually not the default values
• Even if user is aware of it, user has no way to use the default values (since drop down is not present)

I think case (2) should behave like case (3).

To Reproduce

1. Publish any chart with only two values.yaml. For example:

   • values.yaml
   • values-demo.yaml

2. Using kubeapps UI, try to deploy the chart, going to the YAML editor screen

3. Notice that the kubeapps UI is presenting a set of values from values-demo.yaml, without any visual hints from the UI

4. Also notice that there is no way to view or use the default values.yaml

Expected behavior

When a chart has only default values.yaml plus one custom values.yaml, "Default values to use" drop down should be presented.

Desktop (please complete the following information):

• Version 13.1.0 (appVersion 2.8.0)

Screenshots

Case (1) - only default values.yaml

Chart.yaml
values.yaml

Case (2) - 2 values.yaml - notice how confusing it is

Chart.yaml
values.yaml
values-test.yaml

Case (3) - 3 values.yaml

Chart.yaml
values.yaml
values-test.yaml
values-prod.yaml

[absoludity]

Thanks for the feedback @rophy . I few things to consider:

The flaw is on case (2). In such case, the UI is presented as if the values is the default one, i.e. the UI looks exactly like (1), but with a customized values.

* User has no way to know that this is actually not the default values

So this was the intent, because one of the two main use-cases that we had was that Kubeapps admins were wanting to simplify deployments for their users. Rather than being presented with the list of all the possible options that can be configured with their default values, admins were asking to be able to provide a single, simplified, custom values file which would be presented to users as the only option, so that users have a simplified experience.

* Even if user is aware of it, user has no way to use the default values (since drop down is not present)

I know it's not helping your desire here (that users can choose the file that they actually see in the UI), but just to be clear, the default values is still being used. When the user views the custom values, makes any changes, and submits, those values are still being merged with the original default values to deploy (ie. it's doing a helm --values values.yaml --values custom-values.yaml where Helm gives priority to the right-most values file)

I think case (2) should behave like case (3).

It is trying to serve a separate use-case, as above, but I totally agree it's confusing when we don't yet have documentation about this. The other use-case is (3), where people weren't necessarily wanting to simplify the deploy process, but rather, provide multiple values for different scenarios.

So ultimately, the issue here is that the determinant between use-case "simple values deployment (no options)" and use-case "multiple values for different scenarios" is currently len(extra values files) == 1 which can be confusing (especially without documentation).

So in addition to documenting the multi-value support, we could find and choose some other determinant, so that @rophy's in-between use-case of "Add a single optional values file for the user to choose from" is possible, (and it would also make the decision between the other two use-cases more explicit, rather than being surprising).

[rophy]

Thanks for clarifying the rationales. For the case of "simple values deployment (no options)", I was assuming this should be covered by (1) through customizing default values file, but now I do understand the intention.

Can't we cover both cases by having (2) behave like (3), but with the extra values file selected by default? User gets the customization, awares of it, and can disable or adjust such customization if one wishes to do so.