Allow to override Helm values from Kubeapps

[dud225]

Summary
Some settings are server-specific so it may make sense to be able to set them for the whole platform rather than on a per-chart basis.

Background and rationale
We have a chart that sets up an ingress and a TLS certificate and we have multiple Kubeapps server each with its own FQDN. As a result, when an user creates a new Helm deployment he also must make sure the ingress FQDN set from the Helm values is correct.

Here is the part of the chart that creates this ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:     
  name: my_ingress
  namespace: {{ $.Release.Namespace }}
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt
spec:
  tls:
    - hosts:      
        - {{ quote .Values.ingress.host }}
      secretName: {{ quote .Values.ingress.host }}
  {{- end }}
  rules:    
    - host: {{ quote .Values.ingress.host }}
     [...]

The problem with this implementation is that the user often forget to put the correct value to .Values.ingress.host, not to mention when he's not even aware of it.

Description
It would be nice to be able to set such value globally from Kubeapps as those kind of settings pertain to server-wide configuration.

Additional context
There is a similar request for schema: #3535.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[absoludity]

Hi @dud225 . I've recently landed some functionality that allows a chart to have an extra values file with your own defaults and at first thought this might help with this issue, but on re-reading, I see you're after a solution that sets these defaults for all charts that are used on the kubeapps instance.

So currently, adding a values-mycompany.yaml to each chart, which sets the defaults you want (as well as the values which are relevant for your users), will result in those values being displayed (and used) by default (in the unreleased Kubeapps), but I'm not sure we can provide the functionality for Kubeapps to supply a values yaml snippet to all charts deployed on the server. This requires the assumption that all charts have shared fields (which the Bitnami catalog charts do, but I'm not sure there's a standard outside of that).

[dud225]

Hello @absoludity
Thanks!
No no I only have this use-case with a single chart (that I control), sorry if my wording wasn't clear.

So currently, adding a values-mycompany.yaml to each chart

How does this additional values file has to be set? Could you point me to some material where I could learn more about this feature?

[absoludity]

I've not yet written up the documentation (since it's not yet released, though I'll start preparing that soon when I finish the related functionality), but it is use-case 1 from #5692 . It should be as simple as ensuring that the chart package includes a single extra values file (called values-<whatever>.yaml) in the root of the package.

That file will then be used in the UI by default, so the assumption is that it includes the values you, the author, want to ensure are set by default as well as those you want your users to be able to modify. It does not replace the chart's actual values.yaml file but rather is applied on top of the normal defaults, so only needs to include the defaults you want to highlight or change.

Again, it's not been released, I've only just QA'd it on our development images. Hope that helps!

[absoludity]

No no I only have this use-case with a single chart (that I control), sorry if my wording wasn't clear.

I was going to ask why you don't then just update the values (and you wouldn't even need this new functionality), but I think your point is that it needs a different value depending on which cluster the user uses the chart, so you'd effectively need one chart per cluster right? So the new functionality of the extra values won't help you there either.

That makes sense then why you're after something that can be set on the Kubeapps instance itself, so that the one chart can be used on the different clusters and automatically have the correct default. This isn't something currently supported, but may be something we can think about for the next phase of the custom values functionality (the current initial phase is just supporting extra values in the actual package, but we will then be looking at supporting extra values from outside the package).

[dud225]

I think your point is that it needs a different value depending on which cluster the user uses the chart, so you'd effectively need one chart per cluster right?

Yes exactly.
When I mentioned:

we have multiple Kubeapps server each with its own FQDN.

I meant that we have multiple single-host Kubernetes installation (powered by Microk8s) and each of those server has Kubeapps deployed on it. So when one wants to deploy our in-house chart, one has to be careful to set the Helm values host accordingly.

For now I've worked around this matter by implementing it from Helm: the correct per-server values is set in a ConfigMap and its values is fetched from Helm thanks to the lookup function. As a result I'm not impacted by this missing feature, so if you feel that this rather pertains to a niche use-case feel free to leave this idea aside.