(feat): Optional chart dependencies

[sstarcher]

Currently if I to create a chart that say depends on mysql, but other users want to use the same chart with an external mysql server we would have to do one of three things.

1. The mysql chart would have to have a flag that disabled installation of mysql similar to how Deis is installed. This would require flags being inserted into any chart that could be used as a dependency - https://github.com/deis/monitor/blob/master/charts/monitor/charts/influxdb/templates/monitor-influxdb-deployment.yaml#L1
2. The mysql chart would have to not be a dependency of the primary chart and a user would have to pre-install mysql chart and pass parameters to the primary chart. This is a less desirable user experience.
3. Helm support for optional dependencies. Possibly a built in helm flag that allows for disabling a dependencies. Similar to Values possibly a build in Value of Value.${chart_name}.disable = true. So in this situation --set mysql.disable=true or a --set mysql.off-cluster=true

[sstarcher]

My request is similar in nature to #1568, but is a different use case.

[technosophos]

Yeah, it's another use case for selectively enabling/disabling charts. And your use case is very much a common case. Lots of applications (like Drupal, Wordpress, etc.) can support several different database backends.

[TerraTech]

@technosophos I too would like to disable the mysql dependency for things like WordPress, MediaWiki, etc where I'm using a separate MySQL backend server independent of Kubernetes.

My use case for MediaWiki is to avoid the initial install, and have a different UI frontend that will take in the values required to build a proper LocalSettings.php. The database tables will also be setup external of their install script, via a base database table image and tweaked for different users using an external and pre-existing MySQL server. When the user requests a MediaWiki, we ask a few questions, do all the heavy install lifting on the backside, and they login directly to an 'after-install' MediaWiki spooled up and ready to go.

One thing I ran across was StackSmith https://bitnami.com/news/press-releases/bitnami-stacksmith-beta-google-container-reg and also the concept of making things like WordPress a module plugin to Bitnami's LAMP stack.
https://bitnami.com/stack/wordpress/installer
https://bitnami.com/stack/lamp/modules#wordpress

Right now, the only option I can see is to clone the repo and hack up the chart with 'if' blocks as noted in: #1568 (comment)

Overall, Charts is a great project however things like database backends should not be a hard dependency and should be more Lego like with a chart being able to specify its backend (none, MySQL, MariaDB, PostgreSQL, etc) though composition and making the chart value names more generic.
e.g. (for MediaWiki)
mariadb.mariadbRootPassword ==> database.rootPassword

also:
database.backend.chart: disabled (or false)
database.host: mysql.example.com
database.user: bruce
(and so on)

(or the name of an existing database chart)
database.backend.chart: enabled (or true)
database.backend.chart.name: mariadb
database.backend.chart.version: 0.5.2
database.backend.chart.repository: https://kubernetes-charts.storage.googleapis.com/
...
(just an example of various value names, subject to naming to whatever makes most sense in a generic way)

then the whole generic database.* hierarchy could feed whatever values are required by the requested database backend chart. I'm not sure if the values would map 1:1 without some sort of value conversion/mapping adapter between MediaWiki and MariaDB (or PostgreSQL, etc) Chart values.yaml. I do believe this might be a viable step in making Charts more composable with a plugin methodology.

[kfox1111]

Same here. Optional chat deps would be great.

[technosophos]

@TerraTech I think much of what you are talking about is similar to the Deis Workflow charts, where they support multiple backends, and you merely need to choose one. The top-level chart is here: https://github.com/deis/workflow/tree/master/charts/workflow

Check out how they did their storage system. @kmala is the designer of that chart.

[technosophos]

I believe this is now effectively resolved with the new tags/conditions addition in Helm 2.2.0:

https://github.com/kubernetes/helm/blob/master/docs/charts.md#tags-and-condition-fields-in-requirementsyaml

Feel free to re-open if I misunderstood.