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

151–160 of 667 posts

Re: Why are we templating YAML? (2019)

#151

Post by matharmin »

krapp wrote: post #97
Draiken wrote: post #72

I agree that YAML templating is kind of insane, but I will never understand why we don't stop using fake languages and simply use a real language. If you need complex logic, use a programming language and generate the YAML/JSON/whatever with it. There you go. Fixed it for you. Ruby, Python, or any other language really (I only favor scripting ones because they're generally easier to run), will give you all of that wi…

You shouldn't need the full complexity and power of a Turing complete programming language to do config. The point of config is to describe a state, it's just data. You don't need an application within an application to describe state. Inevitably, the path of just using a programming language for config leads to your config becoming more and more complex until it inevitably needs its own config, etc. You wind up with…

I have a recent example of rolling out IPv6 in AWS:

1. Create a new VPC, get an auto-assigned /56 prefix from AWS.

2. Create subnets within the VPC. Each subnet needs an explicitly-specified /64 prefix. (Maybe it can be auto-assigned by AWS, but you may still want to follow a specific pattern for your subnets).

3. Add those subnet prefixis to security / Firewall rules.

You can do this with a sufficiently-advanced config language - perhaps it has a built-in function to generate subnets from a given prefix. But in my experience, using a general-purpose programming language makes it really easy to do this kind of automation. For reference, I did this using Pulumi with TypeScript, which works really well for this.

Re: Why are we templating YAML? (2019)

#152

Post by worldsayshi »

ithkuil wrote: post #146
TheFuzzball wrote: post #26

I just knew this would be about Kubernetes when I saw the title. The Kubernetes API is fairly straightforward, and has a well-defined (JSON) schema, people should be spending a bulk of their time learning k8s understanding how to use the API, but instead they spend it working out how to use a Helm chart. I don't think Jsonnet, Ksonnet, Nu, or CUE ever gained that much traction. I'm convinced most people just use Kust…

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.

Re: Why are we templating YAML? (2019)

#153

Post by lpointal »

bayindirh wrote: post #129
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.

This is an .ini: [section] option=value it the way you want it. ; And these are comments. That's all. I don't argue. I use TOML too, but it doesn't change that it's an ini++. You can treat an .ini file as a TOML file (well, maybe comments needs some changing, but eh), they're not different things. I don't think, even though TOML has some official spec, all parsers are up to it, and may have disagreements between them…

> I don't think even though TOML has some official spec

Read it on https://toml.io/ (Full spec on upper-right… with its evolutions up to final 1.00 version).

Re: Why are we templating YAML? (2019)

#155

Post by speleding »

Draiken wrote: post #72

I agree that YAML templating is kind of insane, but I will never understand why we don't stop using fake languages and simply use a real language. If you need complex logic, use a programming language and generate the YAML/JSON/whatever with it. There you go. Fixed it for you. Ruby, Python, or any other language really (I only favor scripting ones because they're generally easier to run), will give you all of that wi…

Completely agree, my wish is that anything that risks getting complex uses a Ruby-based DSL.

For example, I like using Capistrano, which is wrapper around rake, which is a Ruby based DSL. That means that if things get tricky I can just drop down to using a programming language. Split stuff into logical parts that I load where needed and, for example, I can do something like YAML.load(..file..).dig('attribute name') or JSON.load from somewhere else.

Yes, you risk someone building spaghetti that way, but the flip side is that a good devops can build something much easier to maintain than dozens of YAML and JSON files, and you get all the power from your IDE and linters that are already available for the programming language, so silly syntax errors are caught without needing to run anything.

Re: Why are we templating YAML? (2019)

#156

Post by sgarland »

throwaway143829 wrote: post #2

This article made me think it'd be nice to generate k8s JSON using TypeScript. Just a node script that runs console.log(JSON.stringify(config)), and you pipe that to a yaml file in your deploy script. The syntax seems more sane and has more broad appeal than jsonnet, and I'd wager that the dev tooling would be better given good enough typings. By the way the answer to the question "why are we templating yaml?" is: pe…

> copy and paste from the web

Hot take, this is a terrible idea, and is why so much cloud infra is monstrously expensive (and bad).

People need to stop making infra easy. It’s not supposed to be easy, because when you make a bad decision, you don’t get to revert a commit and carry on with life. You don’t understand IOPS and now your gp2 disk is causing CPU starvation from IOWAIT? Guess you’re gonna learn some things about operating within constraints while waiting for a faster disk to arrive at the DC! Buckle up, it’ll be good for you.

I’m fully aware that I sound like a grouchy gatekeeper here, and I’m fine with it. People making stupid infra decisions en masse cause me no end of headaches in my day job, and I’m tired of it.

Re: Why are we templating YAML? (2019)

#157

Post by bayindirh »

lpointal wrote: post #153
bayindirh wrote: post #129

Earlier quoted context omitted.

This is an .ini: [section] option=value it the way you want it. ; And these are comments. That's all. I don't argue. I use TOML too, but it doesn't change that it's an ini++. You can treat an .ini file as a TOML file (well, maybe comments needs some changing, but eh), they're not different things. I don't think, even though TOML has some official spec, all parsers are up to it, and may have disagreements between them…

> I don't think even though TOML has some official spec Read it on https://toml.io/ (Full spec on upper-right… with its evolutions up to final 1.00 version).

Oh sorry, I missed a comma. It should read: "I don't think, even though TOML has some official spec, ..."

Fixed the comment too.

I know TOML has an official spec.

Re: Why are we templating YAML? (2019)

#158

Post by kungfufrog »

There's 2 things on the horizon here for Kubernetes that give me hope. KCL, its own configuration language, and Timoni, which builds off CUE and corrects some of the shortcomings of Helm.

Though these days, OLM and the Quarkus operator SDK give you a completely viable alternative approach to Helm that enables you to express much more complex functionality and dependency relationships over the lifecycle of resources. An example would be doing a DB backup before upgrading to a new release etc. Obviously this power comes at a cost.

Re: Why are we templating YAML? (2019)

#159

Post by liveoneggs »

TheFuzzball wrote: post #26

I just knew this would be about Kubernetes when I saw the title. The Kubernetes API is fairly straightforward, and has a well-defined (JSON) schema, people should be spending a bulk of their time learning k8s understanding how to use the API, but instead they spend it working out how to use a Helm chart. I don't think Jsonnet, Ksonnet, Nu, or CUE ever gained that much traction. I'm convinced most people just use Kust…

k8s make me miss xml

Re: Why are we templating YAML? (2019)

#160

Post by Brian_K_White »

bayindirh wrote: post #129
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.

This is an .ini: [section] option=value it the way you want it. ; And these are comments. That's all. I don't argue. I use TOML too, but it doesn't change that it's an ini++. You can treat an .ini file as a TOML file (well, maybe comments needs some changing, but eh), they're not different things. I don't think, even though TOML has some official spec, all parsers are up to it, and may have disagreements between them…

Zomg how did you magically read my brain to produce a perfect example of what I was thinking even though there is no IEEE spec? It's unpossible!
Post reply on HN