4 ms·

The worst thing with Helm charts is not the YAML, or even the text replace botch-jobs, but that they seem to think that a Go stacktrace is reasonable error repo

by vidarh 3y ago

The worst thing with Helm charts is not the YAML, or even the text replace botch-jobs, but that they seem to think that a Go stacktrace is reasonable error reporting. I don't think I've ever worked with a tool with such awfully useless error messages. But I agree, it'd be better if the template expansion was actually structural and not just text. The huge amount of "| indent 8" etc. in Helm charts is such a stench that by about the second time people encountered that they ought to have made a better template expansion mechanism top priority.

sethammons 3y ago
You have an error on line one. Good luck
- amath 3y ago
  Ah, this had me laughing.
fatherzine 3y ago
Unlikely it will ever get better. First to market with a prototype tool, gains market share and momentum. Eventually the enthusiasm fades off and people start hating it, for good and sometimes bad reasons. Yet users are stuck because change is expensive and risky. The team is stuck because any change risks becoming the straw that broke the camel's back, possibly cascading through the user population. Story of our young industry.
- vidarh 3y ago
  I think you're part right in that I don't think they will make any backwards incompatible changes. But they could still make things a lot better in two simple ways: * Fix error reporting. Nobody is doing anything that relies on the current error reporting anyway because it's near useless. * Add a slight templating change that means "after this parses as valid YAML, expand this bit, and check that the expansion is itself valid YAML before merging it in" with options to either replace the node, or merge in adjacent (the latter to insert in lists etc). You can do that without backwards incompatible changes by making a syntax change that still uses the go {{ ... }} blocks, but that starts with a directive they can make simply expand to a new template processing directive in the first pass. Then just add a second pass that operates on a parse tree (I've just written a template expansion mechanism that works on json/yaml parse trees, in fact; if we didn't need Helm charts primarily for distribution to partners that I don't want to make use a custom deployment tool, I'd be tempted to replace our Helm charts with an expansion of that. Better error reporting and being able to avoid the incessant "| indent .." blocks and ensuring the output either generates valid yaml or can "contain" the error report to the generated sub-block would make it so much easier to use.

by vidarh 3y ago

sethammons 3y ago

You have an error on line one. Good luck

amath 3y ago
Ah, this had me laughing.

fatherzine 3y ago

Unlikely it will ever get better. First to market with a prototype tool, gains market share and momentum. Eventually the enthusiasm fades off and people start hating it, for good and sometimes bad reasons. Yet users are stuck because change is expensive and risky. The team is stuck because any change risks becoming the straw that broke the camel's back, possibly cascading through the user population. Story of our young industry.

vidarh 3y ago
I think you're part right in that I don't think they will make any backwards incompatible changes. But they could still make things a lot better in two simple ways: * Fix error reporting. Nobody is doing anything that relies on the current error reporting anyway because it's near useless. * Add a slight templating change that means "after this parses as valid YAML, expand this bit, and check that the expansion is itself valid YAML before merging it in" with options to either replace the node, or merge in adjacent (the latter to insert in lists etc). You can do that without backwards incompatible changes by making a syntax change that still uses the go {{ ... }} blocks, but that starts with a directive they can make simply expand to a new template processing directive in the first pass. Then just add a second pass that operates on a parse tree (I've just written a template expansion mechanism that works on json/yaml parse trees, in fact; if we didn't need Helm charts primarily for distribution to partners that I don't want to make use a custom deployment tool, I'd be tempted to replace our Helm charts with an expansion of that. Better error reporting and being able to avoid the incessant "| indent .." blocks and ensuring the output either generates valid yaml or can "contain" the error report to the generated sub-block would make it so much easier to use.