Puppet or Chef: The configuration management dilemma

Configuring the configurers
As I played around with Puppet and Chef, I started to run into the typical bitrot hassles that plague all computer software systems but especially bedevil large open source ecosystems like Puppet and Chef. Yes, these ecosystems are wonderful wellsprings of creativity, but they're also sources of friction as all that creative genius heads off in different directions. In theory, you can keep plugging in multiple modules and your system will get better and better, but in reality they start competing for different versions of essential modules. The software doesn't plug together as easily as Lego bricks.

For instance, after installing a few modules, my version of Puppet started complaining that it was stuck with version 0.0.6 of the Java_KS library, which it labeled "invalid." The pe_mcollective library wants version 0.0.3 of Java_KS, and it was not going to accept the newfangled 0.0.6, even if that's what all the whippersnappers thought was cool. For grins, I tried the puppet module upgrade command, which sometimes works, but it couldn't downgrade me. It was smart enough to realize that the newest version of the module (1.0.0) wouldn't satisfy the pe_mcollective library's complaints either. I would guesstimate that 90 percent of my time with Puppet and Chef was spent satisfying their configuration gripes.

This is a deep issue for software development that everyone complains about regardless of whether they're running Linux or Microsoft. In a blog post explaining why he switched to a Mac, noted open source developer Miguel de Icaza said of the Mac, "I did not miss having to chase the proper package for my current version of Linux, or beg someone to package something. Binaries just worked."

To be fair, when I installed Chef on my Mac, I had to install plenty of other libraries before it would "just work." A choice aside from the installation guide to Nokogiri, an XML parser, is noteworthy here:

Please note that Leopard comes bundled with libxml 2.6.16. Someone in Cupertino MUST be having some fun at our expense, because this is clearly somebody's idea of a bad joke. 2.6.16 was released Nov 2004 and is really quite buggy. We here at Nokogiri HQ advise strongly that you do not use this version.

In the world of Puppet and Chef, I often found myself with software that wouldn't "just work" for me, at least until I fiddled a bit more. I had to reinstall modules again and again. It was not uncommon for the software to fail, fail, fail, then work perfectly for inexplicable reasons. To view the glass as half-full, I can say that the software was constantly trying to heal itself and install the right modules. This means it can heal itself a bit in the process of failing, then succeed the next time.

In other words, be prepared to write code or at the very least think like a developer and juggle all of the libraries. The Chef documentation includes a page that explains "just enough Ruby for Chef." If you're working with Puppet, you'll need to get a bit dirty figuring out what to do with the custom language unless you try to reprogram the tasks using Ruby.

Before getting too annoyed by these endless tiny glitches, it's worth remembering the alternative: visiting dozens, hundreds, or perhaps thousands of machines and running or rerunning the same script. Puppet and Chef are leaps and bounds better than writing your own scripts and trying to keep them standardized. They're not a push button tool for managing what is still very much a command-line game that requires command-line code.

Many people will complain about the hassle of interacting with the various plug-in authors in the sometimes sketchy and often hit-or-miss world of open source modules. But working with the open source modules forces the internal users to standardize their scripts and build out an architecture that is often better documented and easier to understand. In other words, using the modules brings discipline.

Yes, you will still have endless internal and external conflicts. Yes, you'll be working in a domain-specific version of Ruby or JSON. Yes, the command line will be a big part of it. But all of this structure will bring some order to the vast empire of cloud machines that you have waiting to be maintained and perhaps even upgraded.

This structure is why people end up both hating and loving tools like Chef and Puppet. They're complicated and sometimes maddeningly unforgiving, but they bring a needed discipline to maintaining all of those servers we bought. We created them with that cloud magic, and now we need some cloud sauce to pour over them to keep that magic alive.

This article, "Puppet or Chef: The configuration management dilemma," was originally published at InfoWorld.com. Follow the latest developments in application development, cloud computing, and open source at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.