Puppet use today

Posted Jan 23, 2025 11:40 UTC (Thu) by taladar (subscriber, #68407)
In reply to: Puppet use today by himi
Parent article: Puppet fork OpenVox makes first release

> The biggest thing is really the module library that's available - yes, you can write your own Ansible/Puppet/etc code to manage your particular deployment of whatever, but almost all of the time it's a hell of a lot faster to use code written by someone else.

This is not my experience at all using Puppet. It is usually much faster and easier to write something custom than to attempt to figure out which of the badly written or maintained modules publicly available are suitable for all platforms we use, will be maintained long enough to be usable,...

The custom solution also tends to be much better in this space because a large part of config management is to hard-code all the configurable parameters a software allows but that are the same for your entire administrative domain and to only have to specify the things that are different for you for every system. And also to avoid specifying these same values multiple times for implementation, monitoring,... resources.

Puppet use today

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

> This is not my experience at all using Puppet. It is usually much faster and easier to write something custom than to attempt to figure out which of the badly written or maintained modules publicly available are suitable for all platforms we use, will be maintained long enough to be usable,...

That's where my point about the quality of the module library comes in - there are quite a lot of excellent modules out there, and there are projects that develop and maintain their own decent quality modules (a good example being OpenStack), and that can get you a long way very quickly . . . if your use case fits. Though there are also examples of key modules provided by Puppetlabs that are a massive pain in the arse - I keep being bitten by the apt module, for example, since my use case is more complex than that module wants to allow for. I do definitely find that the collection of custom code that's replacing or working around modules keeps growing, as well as the number of cases where I've had to fork upstream modules (generally temporarily, thankfully).

I think it's also a question of how complex your systems are, and where that complexity sits in the stack - if you're deploying OpenStack there's a mess of complexity in configuring all the various services, but for most use cases only a fairly small part of that configuration needs anything beyond the default value, and the upstream puppet modules make it really easy to just configure those important bits while setting defaults everywhere else. Custom coding all of that is a lot more work than using the upstream modules - I've done it from scratch, it's a lot of scut work but perfectly doable if you have the patience. Configuring other types of software stack would have different trade-offs that mitigate more towards custom coding - e.g. I've found that wrangling systemd configuration is easier with custom code than with upstream modules, because so much of that is a matter of drop-in files and so forth.

Ultimately, though, it gets down to the same core problem: automation of generalised system configuration is a hideously complex and difficult problem space, all real-world attempts to solve it are going to end up being ugly and full of hacks, whether they're hacks you've written yourself or hacks you're reusing from someone else. If anyone thinks their particular solution is perfect I'm pretty confident in saying they're deluding themselves, and probably missing all the nasty edge cases that make this such an unpleasant task . . .