potiuk commented on PR #61065: URL: https://github.com/apache/airflow/pull/61065#issuecomment-3802217268
> What is missing in the proposal is the test-ability. Testability is easy - we already use "render whole template with those set of input parameters and see if the resulting template are as expected" approach. There are no other tests types for our chart - and we can do exactly the same approach here. But it will be **way** faster with kustomize because helm rendering templates with complex jinja code takes seconds (python code, heavily CPU bound that has some potential complex pahts wrapped by helm python rendering), and kustomize is natively supported by kubectl written in go. What really improves in this approach is readability and ability to: a) validate each of teh "incremental changes by the schema (without Jinja processing) b) better separation of features in smaller, independent components (which allow X+Y to work actuallly when you need to do B = X+Y). c) yes woker is one of the most complex, but others suffer with similar problems. My brain hurts when - for code review - I need to switch from Jinja to Xml and back with every.single.line.of.the.template. This hurts the brain as if you put hot wire through your eyeballs :) I think Pareto won't work here - and there is a huge value in something else. If **we** maintainers can extend a basic helm chart with kustomize to add more features, then **others** can do that as well. By implementing our internal helm code as a set of kustomizable extensions, and quite a few of those, it means that it's possible ot extend the chart by others following the same way. Otherwise, our claims that "You can extend the chart on your own" have exactly "0" base. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
