sylva-units: need to support "raw" values, on which no interpretation would happen
a discussion with @alinhg has recently exposed/confirmed the need for sylva-units to support "raw" values, i.e having parts of values that would be exempt from any interpretation of any string looking like golang-template
a use-case is, for instance, the need to customize from sylva-units values the configuration of a component that also uses golang templating (for example Thanos alert rules: https://github.com/thanos-io/thanos/blob/main/examples/alerts/alerts.md).
But there are other examples, especially related to monitoring .
We will need to introduce such an evolution to simplify the design we have adopted to day to deployment-time customization of alerting rules and dashboards (today those rely on locally forking some Helm charts, modifying files in them, building artifacts and pointing a deployment to the artifact). This design was adopted in particular to overcome difficulties with raw files.
units:
foo:
helmrelease_spec:
values:
my_json_field: >-
This should be interpreted by Foo, not by sylva-units: {{ $FooStuff }}One possibility would be to add a _(raw) suffix to the values for which we need such a behavior, like this:
units:
foo:
helmrelease_spec:
values:
my_json_field_(raw): >-
This should be interpreted by Foo, not by sylva-units: {{ $FooStuff }}... and we would evolve the sylva-units templating code to:
- recognize this
_(raw)suffix - when it is present:
- remove it from the key
- don't recurse into the value
Another syntax could be:
units:
foo:
helmrelease_spec:
values:
my_json_field:
_raw_: >-
This should be interpreted by Foo, not by sylva-units: {{ $FooStuff }}One difficulty with this topic is how to support raw fields for values of a unit using a Helm chart X with a schema that we include in sylva-units schema, like sylva-capi-cluster. We would need the sylva-units schema to embed the chart X schema in a way that would allow the special syntax for raw values.