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.

You are correct. And there is an Ansible role for automated management: https://github.com/linux-system-roles/podman/

For this, systemd syntax is a lot better than yaml IMO.

In fact, I'd prefer if the tools you mentioned used something else besides yaml.

> 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.

Out of curiosity, do you know any tools that can't use JSON but can use YAML? JSON is supposed to be valid YAML.

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.

> In fact, I'd prefer if the tools you mentioned used something else besides yaml.

Unfortunately, there norway way that's going happen.

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.

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.

Possibly they are deliberately abusive towards their users.

Odd to call it "systemd syntax" when it predates the invention of systemd by a few decades: https://en.wikipedia.org/wiki/INI_file

That's what it's called: https://www.freedesktop.org/software/systemd/man/systemd.syn...

Yes, it's inspired by INI files.

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.

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.