It's a tool that replaces your usual long systemd unit file with a smaller systemd unit file without boilerplate. Seems like a perfectly good choice to me.
> In fact, I'd prefer if the tools you mentioned used something else besides yaml.
To be fair, most of the popular DevOps tools can work with JSON instead of YAML just fine. And JSON can be easily generated from almost anywhere. I don't think you can work with systemd syntax as easily.
Every YAML parser supports JSON (maybe modulo a couple of weird Unicode chars), but YAML also has features (tags, start/end document) that you can’t express in JSON, so it depends on whether the tool relies on seeing those.
It seemed to me that the original target audience for this is users already familiar with systemd's unit syntax, so making these "unit files" use it as well was a sensible choice.
You can apparently use kubernetes YAML with a .kube target and podman will orchestrate the containers, service, volumes appropriately (on a single node). The only systemd config is a minimal boilerplate to point at the kubernetes YAML.
YAML is such a poor default choice for most things, that it's not odd at all to want to improve on that. In the same vein, people used to say that JSON is a bad format to use because everyone just uses XML.
RedHat basically sponsored the development of Systemd (among other things) so their full-throated support isn't surprising
also, fwiw, YAML is a data serialization format, not a configuration format. people who use YAML and pretend it's a config file format are either lazy, incompetent, or both.
The industry disagrees with your hot take. Configurations will almost always be serialized into some kind of struct, YAML/JSON/TOML/etc work well for this. The neat part is you can use other tools to do the templating to YAML more intelligently, instead of having each tool DIY their own config templating setup.
Hot take? It's literally a data serialization language. Configuration != data serialization for, like, all of time.
No one is mincing words about YAML being used for configuration rather rampantly. They're saying it's a shitshow, and I agree.
> Configurations will almost always be serialized into some kind of struct
No, this is in fact a fairly modern phenomenon due to what I can only imagine is fear of compilers. The grand tradition is for configuration to be parsed and interpreted, which is rather distinct from serialization. Take your editor, or version control software of choice, or nearly every file in /etc, for example.
Standardizing things can be good, sure, and for all the warts YAML is at least consistent, usually, but it's a trend in the wrong direction.
Treating configuration as data is a Choice. I can hear them saying now "oh but being able to template or write a program to manipulate or edit configuration is so much better" -- take a look at how git config works. You can edit interactively with the CLI, read/write arbitrary fields, and yet it's not structured beyond INI style "key = value". There's no schema, and yet nothing is lost. There's certainly no Norway problem.
