After looking into this for longer than I expected I found, that while the official Helm Chart is straight forward to use, I ran into two problems where I don't have a good idea how to solve them yet:

Postgres Password needs to be available to init containers

The init containers run by superset on each release upgrade (i.e. anytime _anything_ changes) require the Postgres admin password. Usually, the password would be stored in a k8s secret and then passed to Helm on calling upgrade: https://docs.bitnami.com/general/how-to/troubleshoot-helm-chart-issues/#credential-errors-while-upgrading-chart-releases

This does not work when using helmfile as passing the --set parameter in helmDefaults.args will pass this to _all_ commands and some of them (e.g. helm list) do not support the flag, making the deployment fail.

It seems it's possible to put this in the values file itself, however this means we'd have the postgres admin password in the values file in plain text.

Right now, I am not sure what to do about this. Superset itself would also support using a SQLite database (which I think would be more than enough for us, it just stores user accounts and queries / dashboards), however this is not supported by the official Helm Chart.

MariaDB Helm Chart does not support multiple dedicated secondaries

As specced out in this ticket, we wanted to run queries from Superset against a dedicated secondary in order to not overload the production systems in case someone on the team unknowingly writes a heavy query. This, however, is not supported by the Bitnami Helm Chart we are using. The only thing we could do here is raise the number of replicas that are backing the secondary service, however these will still use the same service as ingress for any queries. It's also not possible to deploy another release off that chart that only deploys a secondary.

Things we might need to do here are:

• Deploy a standalone replica using some TBD Helm Chart
• Live with the fact that we put extra load on production