Umbrella charts

[nmarcetic]

@blokovi I am also thinking about chart dependencies and umbrella charts. Thing to think about in for #later or next stage of refactoring,

We can scope Core services and make mainflux/core chart as the main chart. Creat micro charts for each add-on that we have and mark them with a condition: optional, then import them in core chart. Each micro chart will have mainflux/core marked as a dependency (you can't run grafana add-on without core).
This way we will avoid hardcoded conditions like if/else in the chart, which grows all the time and will become hard to maintain.
We also get tagging and version management simpler.
People get install only core or upgrade only add-ons without touching core release. It's much more flexible.
It will be much easier to maintain and develop if we decouple it.
If you agree, maybe we can open an issue, market it as enhancement, and continue the conversation there?

Originally posted by @nmarcetic in #20 (comment)

[nmarcetic]

Also from official doc, tips, and tricks

Complex Charts with Many Dependencies
Many of the charts in the official charts repository are "building blocks" for creating more advanced applications. But charts may be used to create instances of large-scale applications. In such cases, a single umbrella chart may have multiple subcharts, each of which functions as a piece of the whole.

The current best practice for composing a complex application from discrete parts is to create a top-level umbrella chart that exposes the global configurations, and then use the charts/ subdirectory to embed each of the components.