4 ms·
I hear you about feeling dumb. I think some early decisions in the k8s ecosystem led to a lot of wasted time and effort, and this frustration. YAML: significan
by heretogetout 4y ago
I hear you about feeling dumb. I think some early decisions in the k8s ecosystem led to a lot of wasted time and effort, and this frustration.
YAML: significant whitespace is always unwelcome but YAML also introduces unexpected problems, like how it deals with booleans. For example, say you have this array:
foo:
- x
- y
- z
You might think this is an array of strings, but you'd be wrong.
It's also difficult to read through a YAML config and understand the parent of each key, especially in code reviews or just on GH.
I believe k8s life would have been easier with JSON configs, where it's impossible to confuse e.g. booleans for strings and where it's easier to understand the object's hierarchy.
Helm's use of gotpl: this choice exacerbates the problems with YAML. Now you're treating a structured language with a text template library. You have to spend energy thinking about indentation levels and how the values will be interpreted by both the templater and k8s.
I think helm would be less frustrating if they chose some templating library that made objects first class citizens. Where you can inject values at specific locations with one-liners or simple blocks of code (e.g. `ingress.spec.rules[0].append(yadda yadda)`)
I'm sure there was debate about these choices early on and I don't have any unique ideas here, so I don't want to be too critical. These are just a couple of pain points I've personally experienced.
- aliswe 4y agofor what its worth, and if im not mostaken, there is some support for JSON, ie. kubectl get deployment xyz -o json
- neurostimulant 4y agoJSON has a different set of problems, e.g. not having multi-line string support.
- jtchang 4y agoIs that yaml not an array of strings? ["x","y","z"]
- Filligree 4y agoI don't happen to have a YAML parser at hand, but I believe it's... ["x", True, "z"]
- heretogetout 4y agoIt's not, y is treated as boolean true.
- karmajunkie 4y agoIs that a k8s thing? Because when I load it in this page[1] it comes out as a string... [1] https://yaml-online-parser.appspot.com/?yaml=foo%3A+%0A-+x%0A-+y%0A-+z&type=json https://yaml-online-parser.appspot.com/?yaml=foo%3A+%0A-+x%0...
- Thiez 4y agoIn YAML 1.2 they fixed it (and also the Norway-problem of "no" meaning false) but many places are still using an older version.
- deleted 4y ago[deleted]
- rustyminnow 4y agoTechnically YAML is a superset of JSON - all valid JSON is valid YAML. So you could write all your configs in JSON and they'd work just fine.
- krapp 4y agoThis discussion from a couple of weeks ago suggests it isn't that simple: not all valid JSON is always valid YAML if your definition of superset requires that JSON would be parsed the same with a YAML parser as with a JSON parser. If you're going to use JSON for config, it's better to use an actual JSON parser. https://john-millikin.com/json-is-not-a-yaml-subset https://john-millikin.com/json-is-not-a-yaml-subset https://news.ycombinator.com/item?id=31406473 https://news.ycombinator.com/item?id=31406473
- rustyminnow 4y agoThanks! That's really interesting. You could mitigate some of the issues and get JSONs "strictness as a feature" by passing the document through e.g. `jq . $file` as a CI step, but I don't think that'd resolve the 1e2 issue. TBH I didn't know you could write numbers in JSON like that, so I imagine it'd be an issue that doesn't come up often. But it's disappointing that it wouldn't just work.
- bmn__ 4y ago> Technically YAML is a superset of JSON That's false. http://p3rl.org/JSON::XS#JSON-and-YAML http://p3rl.org/JSON::XS#JSON-and-YAML
- rustyminnow 4y agoI'd like to amend my statement: Technically YAML is (supposed to be) a superset of JSON - (almost) all valid JSON is valid YAML. So you could write all your configs in JSON and they'd (probably) work just fine (assuming you keep things relatively simple).