[⚠️ important] Deprecation of external database dependency charts

[bjw-s]

Helm chart name

all

Description

This is a notification that we will be deprecating the use of third party database (and similar) dependency charts in the near future.

This means that instead of specifying (for example):

postgresql:
  enabled: true
  ...

chart users will need to think about how they wish to deploy their database, broker, etc with a deployment lifecycle of its own. This can be achieved through an operator, or simply by deploying the (in this example) Bitnami postgresql chart separately from the application chart.

Additional Information

Some background on why we will be doing this:

We are not in control of the dependency chart release cycle. For example, Bitnami moves fast and the way we have things set up now, we would need to release a new chart version every time to keep up.

We also don't want to pin Postgres to v12 and then home-assistant says "we only support v14 now" (something like this happened recently). Meanwhile Bitnami only moves forward with their helm charts on v14. So old Bitnami charts will not be getting new features. That leads to people looking up helm values for their latest chart instead of the version we pin it to.

Also Bitnami doesn't support arm64 architecture on any of their helm charts which makes it useless to those running on that architecture.

There is nothing we can really do about these scenario's without angering at least one group of users and/or taking on a huge maintenance toil burden.

It's a bit of a mess for both us and the end user, but we believe that letting the chart consumer make an educated decision on how they wish to deploy their app dependencies (and which version) provides the best solution.

p.s.: It may seem that we are calling out Bitnami charts specifically, but many of the statements are true for the concept of dependency charts (that are outside of our control) in general. Bitnami provide a great service by offering their Helm charts to the Kubernetes community.

[djjudas21]

I understand why you're making this change - there are several valid reasons - but I have some concerns:

1. It breaks the model of "helm is a package manager for kubernetes" because it no longer provides dependencies.
2. This will raise the barrier to entry for users to start consuming k8s@home helm charts. Installing an application chart and not realising you also have to deploy a database yourself will result in broken deployments, and probably some users blaming the chart.
3. "letting the chart consumer make an educated decision on how they wish to deploy their app dependencies" I think would be reasonable in a work environment where there are devops engineers whose job it is to deploy application stacks. At home, most people probably don't care about scalability but just want a simple standalone database and don't care how it's deployed.

I accept the point about requiring arm64 compatibility, as many home users are probably running on Raspberry Pi etc. Perhaps k8s@home could provide some example methods of deploying postgres/mariadb/redis/etc from upstream charts, to make it as easy as possible for users to start running applications from these charts.

I only spotted this issue as I was looking to contribute an ownCloud chart, but I'll hold off on that as it depends on bitnami/mariadb and bitnami/redis. Thanks.

[onedr0p]

Maybe a good middleground would be to only keep DB deps if an application requires an external database? This would also allow our helm charts that require a DB to be tested in CI.

The person consuming the chart will need to be aware of any extra configuration needed to use an external database if they wanted to not use the built-in apps defaults (e.g. sqlite). We have a lot of charts where it's an optional dependency for example, Home Assistant.

[disconn3ct]

This issue should probably be mentioned a LOT at https://docs.k8s-at-home.com/our-helm-charts/development/databases/

[bjw-s]

Closed in favor of #1761