> <i>Yeah, about that. It turns out that Fedora CoreOS is very much on the side of "cattle, not pets" when it comes to datacenter management. The Fedora CoreOS view is that any time you need to change out the Ignition config, you should reimage the machine.</i><p>> <i>I'm not sure what the ideal Fedora CoreOS strategy for handling disk-based application state is. Maybe it's "don't fuck around with prod enough that this is an issue", which is reasonable enough. I remember that with normal CoreOS the advice was "please avoid relying on local storage as much as you can", but they probably solved that by this point, either with a blessed state partition or by continuing the advice to avoid local storage as much as you can. Further research would be required.</i><p>The Fedora CoreOS docs show mounting a persistent /var as an example,<p><a href="https://docs.fedoraproject.org/en-US/fedora-coreos/storage/" rel="nofollow">https://docs.fedoraproject.org/en-US/fedora-coreos/storage/</a><p>Totally in love with this excerpt, as a decent standalone pitch for systemd and as one of the few examples I've seen of "then I changed my mind about my systemd hate",<p>> <i>Fleet was glorious. It was what made me decide to actually learn how to use systemd in earnest. Before I had just been a "bloat bad so systemd bad" pleb, but once I really dug into the inner workings I ended up really liking it. Everything being composable units that let you build up to what you want instead of having to be an expert in all the ways shell script messes with you is just such a better place to operate from. Not to mention being able to restart multiple units with the same command, define ulimits, and easily create "oneshot" jobs. If you're a "systemd hater", please actually give it a chance before you decry it as "complicated bad lol". Shit's complicated because life is complicated.</i><p>Having a structured composable way to manage complexity has been great for me. Love love love being able to drop in constraints and tunings, in a predictable way.