Re: jsonnet/tanka helm templating
Matt Fisher <matt.fisher@...>
Re-sending as a reply-all.
Have you read through the threads on github? This particular discussion topic has been discussed at length.... Probably once every few months I'd say at least.
I'd highly suggest reading through some of those threads as it may influence many of the design discussions in your HIP.
To clear up some things: Helm 2 had a selectable engine interface since its inception. Chart.yaml provided an optional
One primary concern with prior proposals was they did not provide a solution to the "one size fits all" problem. Some proposals argued that a chart could declare the need for an alternative template engine that does not exist in mainline Helm, relying on a "plugin" model to handle template rendering. That discussion led to further debate on how plugins could be resolved, how the API contract will fit in, how the user is expected to install the right rendering engine for their chart, etc.
Discussing your ideas in a HIP would be worthwhile, but I do want you to understand that this topic has been discussed in the past. I look forward to the proposal.
From: cncf-helm@... <cncf-helm@...> on behalf of Andrey Tuzhilin via lists.cncf.io <andrei.tuzhilin=gmail.com@...>
Sent: Wednesday, May 12, 2021 4:14 AM
To: cncf-helm@... <cncf-helm@...>
Subject: [cncf-helm] jsonnet/tanka helm templating
I want to make a feature HIP to add jsonnet templating to helm. Specifically, I want helm to have tanka-like functionality with plugged kubernetes libs.
1. go templates have lots of well-knows drawbacks
2. adding "pluggable" engine will have very narrow scope:
- general purpose charts would have to use go templates to stay portable
- you can’t add plugged-in (default) libraries for each and every engine, like tanka std library
3. jsonnet + libs solves two main helm templating problems:
- lots of boilerplate code (labels, annotations, name overrides etc.)
- hard to read error prone yaml + go templates syntax
What do you think?