Of all things I would definitely not call it easy to read and write. It has super-weak (see this for examples: https://github.com/cblp/yaml-sucks) dynamic typing, which coupled with requiring awful templating to get anything non-trivial done it has been the cause of many outages.

For real world Kubernetes needs to be addressed I'd argue we need Dhall or something with Dhall-like semantics and goals to have first class support.

YAML actually has one of the worst default behaviors I've seen: automatic conversion of certain strings to bools.

This wouldn't be a problem if YAML required that all strings be quoted...but it doesn't, and there's no "strict" mode to force quotes, so users are extremely likely to end up doing something that behaves unexpectedly.

If you're lucky, you'll spot the problem quickly instead of wasting half a day on it.

Spending 6 hours tracking down a `loadBalancerIp` that should have been a `loadBalancerIP` feels like a problem that shouldn't have happened.

YAML can be validated using JSON Schema/OpenAPI, and somebody does maintain Kubernetes schema definitions, including Kustomize, which can then be used in an IDE for live validation. For example, the Kubernetes extension for VSCode does this.

If you use Helm, writing and validating schemas for Helm value files is trickier, and not something I believe anyone is doing. It should be easier to do. Ideally you should simply put this at the top of a value file:

  $schema: ./schema.yaml

But from what I know, there's no editor/extension, that supports validating through such a declaration. Secondly, Helm doesn't have a way to statically analyze value access. Something like {{ .Values.missTypedKey }} will only be caught when you generate the manifests.

actually k8s validates the yaml, welp it doesn't it validates the json. basically yaml is only the format the operators get, internally it uses json.

You know i actually agree with you but, as a manager of other engineers, people never stop complaining about having to edit large amounts of YAML that describe complex objects. At a certain point im forced to acknowledge that its just not ergonomic. Now, I will say that perhaps whats actually happening is the objects that the describe are so complex and numerous that the problem is actually that you need better tools, not that YAML as a format is bad. YAML as used to configure, say Open API specifications, is something people always make my problem. I don't really know why this is because I don't have an issue hacking this stuff up in VIM but people really just don't seem to like it.

The features intended to make it easy to use, in the end lead to surprising behavior, often with values having non-string types where you expected strings. There are some examples in https://www.arp242.net/yaml-config.html.

I haven't had any issues with this in a Kubernetes context- but I can see how this could lead to issues in different contexts

> What's wrong with the YAML?

Nothing at all. Until you start 'templateizing' it (looking at you, Helm).

It's definitely better than JSON (it can even have comments, imagine that). Most people don't bother reading the spec or even examples though, and don't realize how good it actually is.

I wish more people stuck with templating yaml would just issue a toJson instead of fiddling with indentation levels

> Nothing at all. Until you start 'templateizing' it (looking at you, Helm).

This scourge affects JSON too, such as Azure's ARM templates, which also crowbar logic into the format. An abomination!

> It's definitely better than JSON

k8s API supports JSON almost exclusively, basically one could write in Whitespace then convert to it.

In the Kubernetes and Ansible/Salt world it's frequently templatized, and then you need to worry about indentation that you place or your template engine places. Every day I pray that Helm will incorporate support for jsonnet so I never need to touch YAML again.

I made a script for expressing similar deployments (ie homepage-en, homepage-de) in a variety of contexts (test, prod) and their permutations in a single, succinct json file.

It's a bash script though.

Example json:

  {
  "deployments": [
    {
      "name": "site-en",
      "env": {
        "hello": "world"
      }
    }
  ],
  "targets": [
    {
      "name": "dev",
      "context": "aks-dev",
      "env": {
        "ipsum": "dolor"
      }
    }
  ]
  }

You should look into Kustomize. It's built into Kubectl, and lets you do something like this in a much more modular way.

I agree with, and have felt the same pain as you here. But this isn't YAML's fault, IMO, it is that the templaters, like Helm, aren't safe, and don't escape their outputs.

If have a string, and I use that in the middle of a YAML template, I expect a string — I don't expect "300" to become (integer) 300; give me a function for that conversion.

Any HTML templating system that behaved this way would be frowned upon due to the potential for XSS. There's little risk of XSS here, but it's still annoying to get the wrong results.

Why not parse the YAML- manipulate it like you would any other data structure in your language of choice, and then generate the YAML from there?

I don't understand why you would want to directly edit markup language without parsing it. YAML's goal is to represent a data structure so that a human can interact with it. It accomplishes that goal well. If you want to edit that data structure programmatically- no markup language makes sense to use, represent the data structure using your programming language's native representations.

Having to do conditional logic in it, like:

matchExpressions:

  - key: app

    operator: In

    values:

    - myservice

Rather than, if (app=="myservice")

Why would you do this in a Kubernetes context?

Your position here seems to be that YAML is a reasonable configuration language. It kinda is.

But that's not how it's used in Kubernetes. It's used as a declarative DSL that you use to specify your deployments, and it is HORRIFIC. Extremely nested things where the equivalent actual code to do that would be shorter. Things that are inexpressible. Backwards-incompatible changes to your YAML that actually make it impossible to deploy changes that bring your YAML up to spec if your cluster's master node upgraded first.

YAML gives nothing here. jsonnet really isn't a drastic improvement, IMO, except that it lets you express some repetitive parts without having to figure out how many times a template engine is going to indent your YAML.

To specify a podAffinityTerm, amongst others.

The YAML spec has a lot of ambiguity in it which makes correctly parsing it surprisingly complicated.

YAML 1.1 (the most commonly implemented version) also lacks a great way of declaring sets (i.e. unordered collections of unique values).

I actually quite like most of the language a lot but the corner cases can be quite complicated.

YAML is easy to read and write in tutorial documents. It becomes a complete mess in real life and whitespace based syntax is horrendous to debug. We have had endless heartaches due to minor yaml issues and today employ tooling to minimize the amount of yaml engineers write to avoid these issues.

I once put an IPv6 address into YAML. It didn't survive the round trip and nearly caused an incident.

Mostly that it's a single projection of an underlying data model. Where the projection is a snug fit, great. But typically folks want sets of things and suddenly it's a bit chatty.

I'm personally fine with yaml, but specifically k8s yaml config is definitely not concise!

Compare roughly equivalent Compose/Swarm and k8s configs, and you'll see that the k8s one is about 8x bigger.

There is a strict yaml alternative with edge cases removed I recommend.