Puppet use today

Posted Jan 23, 2025 15:55 UTC (Thu) by mbunkus (subscriber, #87248)
In reply to: Puppet use today by himi
Parent article: Puppet fork OpenVox makes first release

> Having made a choice at some point, though, you pretty quickly end up committed to that choice - it's extraordinarily difficult to change the configuration management system you're using without basically rebuilding everything from scratch.

There's no "basically" about it, it's exactly "rebuilding everything from scratch". Over the last 20+ years I've been doing this first with cfengine, then SaltStack & now Ansible, both migrations required full rewrites. First of all the configuration languages used are all different. Next the way things are organized are radically different. Lastly the templating languages used are different.

For example, SaltStack & Ansible both (can) use YAML as the format for their configuration. However, in SaltStack _the whole YAML file is run through the Jinja templating language_ whereas in Ansible Jinja is only used _in certain values of data structures_ (e.g. in the values of hashes, but not in the keys). This alone means that loops in SaltStack are loops in the template, generating multiple instances of whole YAML blocks, whereas in Ansible loops are part of the task description DSL. It's really easy to do things such as data modification in SaltStack as you have the whole expressivity of Jinja at your fingertips, wheras in Ansible you have to rely on built-in support for loops or use really whacky things such as json_query().

What you can use old installations for is as a kind of reminder of what to do for each topic, which files to roll out, which packages to install in which circumstances etc. etc.

For us the journey was well worth it, mostly due to three facts:

1. cfengine's execution model & configuration language is so archaic that migration to any other modern system is worth it just for that reason alone.
2. The amount of content out there for Ansible vastly outweighs the one for SaltStack: documentation, pre-made roles/collections, third-party modules etc.
3. The agent-less way of doing things in Ansible suits us as an MSP with multiple customers with which we share admin responsibilities better than SaltStack's/Puppet's mode with an installed agent, as several of our customers use Ansible as well (on the same hosts we use Ansible on; just a matter of communication who configures what), and that wouldn't work with systems that employ agents tied to certain control nodes.

If there's something I miss about SaltStack is its incredible speed, though. Even if you try things in Ansible such as using Mitogen (which breaks often enough), you can still end up having playbook runtimes that are 10× as long as corresponding execution in SaltStack, or worse.

Puppet use today

Posted Jan 24, 2025 2:26 UTC (Fri) by himi (subscriber, #340) [Link]

> There's no "basically" about it, it's exactly "rebuilding everything from scratch". Over the last 20+ years I've been doing this first with cfengine, then SaltStack & now Ansible, both migrations required full rewrites. First of all the configuration languages used are all different. Next the way things are organized are radically different. Lastly the templating languages used are different.

Yeah, "basically" there is really a weasel word, it's very much rebuilding everything. The main reason for not being more emphatic is that there's a definite difference between replicating the functionality of an existing system and building a whole new system from scratch - a whole lot of decisions have already been made and it's a matter of figuring out how to implement those decisions via the new tooling.

Though that can actually make it harder, since things like module libraries are generally opinionated (even if they're not being explicit about it they have defaults and make assumptions about how things are done), and if there's a mismatch you can end up having to fight the new tooling to replicate what was the default behaviour of the old tooling.

I think the big takeaway is this: systems administration is a mug's game, automating most of it is the only sane thing to do; automating systems administration is /also/ a mug's game, though, so the only sane thing to do is knock off early and enjoy a nice relaxing drink . . .

Puppet use today

Posted Jan 28, 2025 10:01 UTC (Tue) by taladar (subscriber, #68407) [Link] (2 responses)

In my experience sharing admin responsibilities always leads to trouble. The problem is complex enough if you don't have multiple organizations with multiple potentially unknowingly incompatible policies and workflows trying to share it.

Only managing part of a system also removes a large advantage of config management, namely that you can create another system that works in exactly the same way reliably and that everyone using the config management tool will produce identical results in all the small details that otherwise diverge if you tell 5 different admins to perform the same task.

Puppet use today

Posted Jan 28, 2025 10:38 UTC (Tue) by mbunkus (subscriber, #87248) [Link]

That's a pretty purist view that simply doesn't apply to my own situation here, with our customers. I'm not saying it's ideal, but monetary constraints require compromises.

Note that I'm not advocating for this type of setup. My earlier statement only said that using agent-less approaches such as Ansible's makes this type of cooperation possible, whereas agent-based approaches such as SaltStack's simply don't work.

Puppet use today

Posted Jan 29, 2025 0:13 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

Eh. Sysadmin here deploys the "base" machine (OS, monitoring, vulnerability scanning, etc.) and then hands it over to us for our CI deployment configuration layer. It's worked well so far (probably mostly because the former is once-and-done for the most part).