Support additional default values from a package

[absoludity]

The first chunk of work that we can implement from the Kubeapps Custom Package Data is to support custom default value files when they are included within a package.

Use case 1: A single customized default values file

As a Kubeapps operator,
I want to repackage my packageA with a custom default values file (e.g. production-values.yaml)
So that any user who installs package A will be presented with my custom default values.

Use case 2: Multiple customized default values files

As a Kubeapps operator,
I want to provide my package A with multiple default values files (production, staging etc.),
So that any user who installs package A will be able to select one of these default value files as a base for the deployment.

Or, from the user point-of-view:

As a Kubeapps user,
I want to install my company's custom packageA,
So that I can choose from the defaults provided by my company for my situation.

Task breakdown

This task will focus enable the functionality for the Helm plugin only, though the

• Define a format for including data in the packages themselves. This will be plugin-specific, so for Helm (and flux) it can be just matching on values-*.yaml file in the root. If we later decide to support this functionality with Carvel, it will similarly be an extra file in the bundle's root.
• Design and implement support for the in-package custom defaults in the Kubeapps-APIs service, so that the Helm plugin is able to populate additionally a custom_defaults_values map, which, together with the existing “default_values”, allows the package’s original defaults to be overlaid with custom values.
• Implement the dashboard changes so that, when present, custom defaults can be selected by the user. By default, the first custom defaults will be selected (sorted alpha-numerically). When only one custom default is present, it will be used without giving the user a selection at all.

[absoludity]

So the first case is now done (well, in review). I'm looking at the case 2. The installation of a package seems straight forward enough (small UX change), but where I'm uncertain with case 2 is when viewing an installed appication: Kubeapps will (currently) not have a way to know which default value was used by the user during install.

Fundamentally, there's no way for Kubeapps to know without us storing some indication with the release itself, which seems like the obvious solution: a custom values.yaml can include a custom-defaults-name field, for example:

# Copyright 2022 the Kubeapps contributors.
# SPDX-License-Identifier: Apache-2.0

image:
  repository: bitnami/nginx
  tag: "1.23.3-debian-11"
  pullPolicy: IfNotPresent

custom-defaults-name: values-production.yaml

This field will not be set when the package defaults were used, but if a custom default values was used, the field will be set to the name of the file. This will allow Kubeapps to identify the file to use as the base overlay, presenting this (with the diff view) to the user. The cost is small, the behaviour on failure is simple and expected (uses main default).

Another option would be to use a custom kubeapps annotation on the helm release object (secret or config map). The benefit would be that it's not visible to the user and so less likely to change unexpectedly (though still possible), and it's not dependent on the chart author remembering to add the field etc.

For this reason, I'm leaning toward the annotation rather than an explicit value in the values file. Thoughts?

[absoludity]

For this reason, I'm leaning toward the annotation rather than an explicit value in the values file. Thoughts?

Answering myself here, but while working on the multi-value option, I realised that actually, by default, we show the use the deployed values when they upgrade, so it works quite well out of the box. For example, this is after deploying the chart with one of the custom default values selected... when upgrading it just looks normal since it uses the deployed values for the diff:

You can instead choose to switch the diff to be against the package defaults if you want to:

I think this is a great starting point for the feature. If we later get feedback and have resources, we could enable diffing against other defaults in the package, but not necessary at the moment, in my opinion.