camunda-platform-helm
camunda-platform-helm copied to clipboard
[ENHANCEMENT] Proposal to deprecate pre-installed databases (externalDatabase as only option) (elasticsearch, postgresql, keycloak)
Describe the use case:
I'm realizing that maintaining different ways of configuring keycloak, elasticsearch, and postgresql is adding a lot of complexity to these helm charts unnecessarily. For example:
- Today, I was dealing with an issue that occurred on externalDatabases only when using the compatibility layer
- Last week, I was dealing with an issue where we were using frontend (ingress urls) and backend urls (kubernetes service names) differently when connecting to keycloak which sometimes causes trouble with the
iss
field in auth tokens.
It also leaves us unnecessarily opinionated when it comes to how you should install these things. Do we really care if someone chooses to use the Elastic Operator, or bitnami/elasticsearch image when all our applications take is a connection string and a supported version of the app? Or whether a customer chooses to use a cloud native database solution or not?
Furthermore, there are plenty situations where a customer experiences an issue in a non-Camunda component and assumes that it's a problem with Camunda as a product, such as:
- The warnings propogated through the bitnami/postgresql helm chart about
non-table values
- The Keycloak issue above regarding backend/frontend addresses
- Elasticsearch's initContainer needing to be able to execute a
sysctl
command to change a kernel runtime parameter (vm_max_map).
Describe the enhancement/feature:
I propose that there should only be one way of setting these connections up, and that should be through the externalDatabase
options per-component. For development use-cases, there may still need to be a guide or script for how to set up a postgresql instance or elasticsearch instance for testing, but I think that would be easier to maintain than maintaining the subcharts.
Desired outcome and acceptance tests: