Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why are we templating YAML? (2019)

leebriggs.co.uk

Post reply on HN
Print view View original

181–190 of 667 posts

Re: Why are we templating YAML? (2019)

#181

Post by nhumrich »

I will tell you exactly why we template yaml. Its the exact same reason every code base has ugly parts. And that's the evolution of complexity.

At first, you have a yaml file. No templates, no variables. Just a good old standard yaml. Then, suddenly you need to introduce a single variable. Templating out the one variable is pretty easy, so you do it, and it's still mostly for humans to edit.

Well, now you have a yaml file and template engine already in place. So when one more thing pops up, you template it out.

8 features later, you wonder what you've done. Only, if we go back in time, each step was actually the most efficient. Introducing anything else at step 1 would be over-engineering. Introducing it anywhere else would lead to a large refactor and possible regressions.

To top it off, this is not business logic. Your devs are not touching this yaml all that much. So is it worth "fixing", probably not.

Re: Why are we templating YAML? (2019)

#182

Post by Gormo »

amelius wrote: post #150
armchairhacker wrote: post #38

To me YAML seems like the CoffeeScript of JSON, and unlike CoffeeScript I don’t understand why people are still using it. I guess XML and JSON are too verbose. But YAML is so far in the opposite direction, we get the same surprise conversions we’ve had in Excel ( https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr... ). Why is “on” a boolean literal (of course so are “true”, “false”, as well as “yes”, “no”,…

Does anyone know which format Git uses? Is it YAML? Or TOML? Or something in between?

Git uses its own ini-style conf format which diverges from TOML.

Re: Why are we templating YAML? (2019)

#183

Post by ryandv »

worldsayshi wrote: post #152
ithkuil wrote: post #146

Earlier quoted context omitted.

I love the idea of keeping it simple and I do try to use kustomize or even plain yaml as installation method as much as possible. But in practice when managing large systems you inevitably end up benefiting from templating

I've begun thinking that if you start thinking about templating you might be better off building an operator. Operators aren't as well understood and documented. But in my mind an operator is just a pod or deployment that creates on demand resources using the k8s api.

The purpose of an Operator is to realize the resources desired/requested in a (custom) resource manifest, often as YAML or JSON.

You give the apiserver a document describing what resources you need. The Operator actually does the work of provisioning those resources in the "real world" and (should) update the status field on the API object to indicate if those resources are ready.

Re: Why are we templating YAML? (2019)

#184

Post by transfire »

Is Kubernetes using YAML 1.1 still? Because some of the complaints I hear shouldn’t be an issue with 1.2.

Moreover the YAML spec allows for specifying the tags recognized per application.

So on two counts, if “on”, “true”, “false”, as well as “yes”, “no”, “y”, “n”, “off”, and all capitalized and uppercase variants, are all boolean literals, it is not YAML’s fault.

Re: Why are we templating YAML? (2019)

#185

Post by jeroenhd »

lucideer wrote: post #59
armchairhacker wrote: post #38

To me YAML seems like the CoffeeScript of JSON, and unlike CoffeeScript I don’t understand why people are still using it. I guess XML and JSON are too verbose. But YAML is so far in the opposite direction, we get the same surprise conversions we’ve had in Excel ( https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr... ). Why is “on” a boolean literal (of course so are “true”, “false”, as well as “yes”, “no”,…

> I don’t understand why people are still using it It's a good comaparator, there are indeed a lot of similarities, but I never understood why anyone ever used Coffeescript whereas I do think I have a solid understanding of why people use YAML. It's more like Python than Coffeescript really: it's not just about simplicity & brevity, it's about terminators. Whitespace-dependent languages are often a pain to format / p…

> I never understood why anyone ever used Coffeescript whereas I do think I have a solid understanding of why people use YAML.

When Coffeescript was invented, it was an advancement on top of the awful Javascript standards at the time. It never went anywhere because Javascript caught up, but Coffeescript had a good reason for existing.

Today, Coffeescript is a remnant of old frontends that nobody has bothered transpiling into Javascript yet, but back in the day it was a promising new development.

Re: Why are we templating YAML? (2019)

#186

Post by aeyes »

rad_gruchalski wrote: post #110
TheFuzzball wrote: post #73

Earlier quoted context omitted.

I think custom code is to be expected, and making it maintainable is what's important. > everything should be made as simple as possible, but no simpler. Helm et al made it simpler than it was, IMO.

Helm is another can of hot garbage. Impossible to vendor without hitting name collisions, can configure only what’s templated. Jsonnet is the way to go with generated helm manifests transformed later. Kustomize with its post-renderer hooks is another can of even hotter garbage.

> Impossible to vendor without hitting name collisions

What problem exactly are you facing? I can change the name of the chart itself in chart.yaml and if the name of the resources collide I change them with nameOverride/fullnameOverride in the values. All charts have these because they are autogenerated by `helm create`.

I vendor all charts and never had this problem.

Re: Why are we templating YAML? (2019)

#187

Post by SiempreViernes »

Brian_K_White wrote: post #132
chx wrote: post #111

Earlier quoted context omitted.

1. I am unaware of a standardized .ini format 2. The native types in TOML are useful.

Shall we bet on what would happen if we asked 10 random people of any IT stripe to write a small sample INI file? Come on.

The problem isn't with the small configuration files, those are just argv put into a file.

Here's an experiment actually worth doing: ask ten people to write a ini file for configuring between 3 and 6 servers where some properties are the same for several servers.

Re: Why are we templating YAML? (2019)

#188

Post by andix »

A lot of people don't know that JSON is valid YAML. You can mix JSON into your YAML wherever you need it.

So if you have issues expressing something complex in YAML (like nested arrays) just write JSON instead.

Re: Why are we templating YAML? (2019)

#189

Post by orphea »

never_inline wrote: post #36
kristiandupont wrote: post #19

Earlier quoted context omitted.

You just pinpointed my biggest peeve with YAML. It looks like it's "human friendly" because there are no scary curly braces. But you still need to get the syntax exactly right, so that benefit is very small. And now you have to keep your finger on the screen while scrolling in order to figure out what a bullet belongs to.

This is least of my worries - just use VScode with plugin which gives red lines on and formats yaml, use yamllint in your CI.

Basically you're saying YAML is unreadable without an IDE or a text editor with advanced highlighting functionality.

Re: Why are we templating YAML? (2019)

#190

Post by youerbt »

Brian_K_White wrote: post #132
chx wrote: post #111

Earlier quoted context omitted.

1. I am unaware of a standardized .ini format 2. The native types in TOML are useful.

Shall we bet on what would happen if we asked 10 random people of any IT stripe to write a small sample INI file? Come on.

We should ask them instead to modify the existing INI file. I bet most would do just fine.
Post reply on HN