Mutate default parameters with jsonnet before being processed
ccremer opened this issue · 2 comments
Context
Many commodore components integrate a Helm chart and expose Helm values through a parameter called helm_values.
The component would often override certain helm values.
Sometimes though it can be necessary to provide config values based on other values.
Consider a component that primarily supports Rancher and OpenShift 4 distributions.
The values for each distro differs greatly, but there is no real way to configure the Helm chart based on another parameters.
For example, if <component>.distro=openshift then the value of <component>.helm_values.securityContext must become null, otherwise default to {fsGroup=1000, etc}. Or the other way round: The chart's default is empty and working for one distro, but for another distro we need to set 5 parameters in various places within the hierarchy, without completely replacing the "tree of values".
Proposal
Add possibility to add a jsonnet filter that can mutate the defaults defined in defaults.yml with custom logic before another step in the compilation process is executed. Think MutatingWebhook in Kubernetes.
It would be enough to just make this filter work before any Helm template is rendered if such filter can't be implemented generic enough (resp. any "position").
As a side effect (provided a generic approach works), such a filter allows easier migration of deprecated parameters. If a "conversion" filter can be placed before all the other jsonnet files, we might get rid of jsonnet code that deals with deprecated parameters in a special way. The conversion filter would simply transform the deprecated parameters into the new structure.
Alternatives
Lookup tables as described in https://syn.tools/syn/explanations/commodore-components/parameters-logic.html as not flexible enough.
- It's very hard to completely replace a "tree of values" without maintaining the complete tree all in the table. One might not want to copy-paste all the chart's default values.
- Complex conditionals with AND or OR become very hard to maintain via tables. Some conditional scenarios are not possible.
Consider switching components which need this to use Kadet + kapicorp/kapitan#875 (once merged and released), that way we could write arbitrary Python to preprocess Helm values.
Another alternative might be to render a helm_values.yaml using a similar approach to the one we've taken to render a kustomization.yaml (see e.g. projectsyn/component-kyverno#67), and then pass that file to Kapitan's helm input type as helm_values_file (cf. https://kapitan.dev/compile/#helm)