[proposal] Reference packaged value files
I am planning to write an HIP about referencing packaged values in
dependency charts. Before doing that, I would like to check if there
is any interest in the proposal, or if I should just implement it as a
Some of our applications are composed by multiple independent
software, bound together by a router. As a practical example, we can
have the following FooBar application:
- Router (routes incoming requests)
- Foo Server (serving /foo/* pages)
- Bar Server (serving /bar/* pages)
* Foobar application needs to be deployed in different environments
(i.e. dev/staging/prod) and different regions (i.e. europe/us/asia)
* Foo and Bar are developed independently, so we should change its
dev/staging/prod/region values in the same repo.
* Some of the application (Router-Foo, Router-Bar in this case) are be
related, so we want to define them in the same place
## Current solutions
Unfortunately I can't see a clean way to do this at the moment, as we
cannot reference packaged value files.
1) organize all possible dimensions (cluster, environment, etc) in
keys with enable/disable switch, and enable/disable from parent chart.
2) write all values in parent chart
Solution one is very hacky, and would greatly complicate our charts.
Solution two will complicate development of each solution, as values
should be modified in multiple parts of the code (in our case, in
## Proposed solution
Ideally it would look something like this:
The dependency section would look something like:
- name: router
- name: foo
- name: bar
## Proposed implementation
We could reference dependencies' *packaged value files* as follows:
`helm upgrade . -f values.yaml -f foo/values.europe.yaml -f
foo/values.yaml -f bar/values.europe.yaml -f bar/values.yaml`
For example, if this is run from `foobar` directory, helm could check:
- if value file exists in the filesystem, it will be used
- if not, we check if the prefix (until `/` char) is a dependency
(name/alias). If it is, we chan look for the file there
This would be preferable to a custom switch, so it can be integrated
with already existing tools (i.e. ArgoCD, skaffold, etc) without the
need of a downstream change.
Any feedback you might have is welcome!