Let me preface this by saying I don’t think this is unique to Puppet Forge, and the problem isn’t even with Puppet Forge itself. Puppet Forge provides an excellent resource for the Puppet community, and I think it provides tremendous value.
But I think that a push towards “configuration management everywhere”, combined with reductions in resources leads folks to think that resources like PuppetForge are a panacea.
Sherman, set the Wayback machine….
A couple decades ago, as Visual Basic started to become popular, and various development platforms were created for simply making programming “attach this pre-made module to that pre-made module and plug in a couple values”, the industry (rightly) cried foul that people would confuse an ability to assemble the software-development version of Lego with actual programming. The difference in ability between “constructing a house from scratch” versus “sticking together some pre-fab materials” was an apt analogy. Some people didn’t necessarily understand how their code worked, or even what it was doing, and still bandied around the title of “programmer”. To a large extent, we’ve dissuaded that sort of practice from continuing (near as I can tell).
In the system administration community, we need to be wary of falling into the same trap. There’s a world of difference between going to PuppetForge, grabbing a pre-made manifest for managing “OpenLDAP”, and that of installing OpenLDAP (even just from yum/apt), and then configuring it yourself. (Better still would be the level of knowledge imparted by compiling from source, but install/configure is a good middle-ground).
When sysadmin’ing a given package becomes “I grabbed the module from PF and installed it, and now it works”, a lot of the knowledge necessary for day to day maintenance is simply missing. What files were installed where? Why were they installed there? Configuration options in a Puppet module that seem benign might actually have much longer-lasting ripple effects than you can realize.
As I said, Puppet Forge is an excellent resource. But it is no substitute for understanding how to do the install in the first place. Puppet Forge should be used for ideas about “how to configure YOUR module,” as opposed to being “the module you use”.
While that seems like I’m saying “reinvent the wheel every time,” because of some weird theme of “not invented here” syndrome, I’m not. What it means is that after the application is installed, months down the road, there’s going to be some sort of problem with it. And if all you know about the configuration of the application is what was exposed to you (or worse, your predecessor) by the pre-made module that was downloaded, your ability to diagnose problems with that application is going to be substantially reduced. Having configured it yourself, from the ground up, and then built a Puppet module on your own (or by referencing existing modules) to recreate that config is most definitely the path to success.
As a profession, we need to be wary of falling into the trap of “Oh this is an easy and quick to solve this, and I’ve got so much other stuff to get done today before I go home.” This is the sort of problem which silently lurks below the surface, and wreaks untold damage when it goes foul.
We’re still early enough in the adoption of “config management everywhere” that it’s not too late to change the direction our collective mindset is heading; to ensure that we don’t end up in a realm of tech-skills disparity the way the programming industry did in the not-too-distant past.
Derek's Rantings and Ravings 3.0 