I’ve been talking with a lot of folks lately about Configuration Management/Automation Systems. Mainly about puppet vs cfengine.

The first question i usually ask people recommending interpreter solutions (ruby, perl, python..) is “Why?”. Why would anyone want an interpreted solution?

I get the point that the scripted languages are usually easier and therefore easy to maintain. This is true if you compare cfengine to almost any other solution. Yes, cfengine is a bit quirky.

So here are the main issues i’ve encountered with interpreted solutions over the past 4 years.

#1 Libraries (Gems and Eggs)

If your config management needs libraries like Ruby’s Gems or Python’s eggs on runtime, then it is clearly a bad idea. Imagine you having to keep libraries up to date, just so your config management runs.

I want my management system to be able to run anywhere, without having to worry about Gem-versions and Egg-versions.

#2 Interpreters (Ruby, Perl, Python…)

Having said the version-part about Gems and Eggs, this applies also to the language it’s written in.

Having the requirement of an actual interpreter for your config management installed is more than unsettling to me, why? Because you will run into issues regarding different OS/Architecture stuff that the language might handle differently/ineffeciently or make it segfault or deadlocking. Also having a common interpreter for config management (like Ruby) gives a whole new front of issues when you’re for example a Rails- or in general a Ruby- coder.

Since you most certainly need a specific version of (e.g Ruby 1.8) to run certain code in your interpreter, plus you might need to keep your libraries/gems/eggs up to date.

So you think my points are all bogus?

Why don’t i just tell you my 1.5y-experience with Puppet back in ‘09 (i think)?

I had puppet running on roughly 40 VMs. The first thing that i found good at the time was, that it is Ruby! I know ruby, awesome! But the feeling that the decision was right, didn’t hold up for long. Having to update multiple libraries AND your config mangement, then you have a severe upgrade-impact.

After having those servers run for a couple of days, i noticed that some of the VM’s puppetd weren’t running anymore. That got me curious, so i started digging. Turned out that puppet somehow crashed quite frequently. One day i decided to let puppet put itself into every VM’s crontab, so it would do a /etc/init.d/puppetd restart every hour.

All was great, until one day my IRC VM was lagging like hell. I did BW checks at home and in the DC, nothing there. Then i logged into the VM Host just to find a couple of VMs running at 100% CPU. Great, now what?

Turns out that ruby/puppetd deadlocked itself while eating 100% CPU - yaaay! I restarted those puppets and all was good for another few months when it hit again. Several puppetd’s dead, another few are just doodling at 100% CPU..

During that time

i had to mingle with different Gem- and Ruby-Versions (as 1.9 was just hitting the scene) just so i could get my management and my development back on track.

Clearly, this is NOT what you want.

So what do i use?

Cfengine. Cfengine. Cfengine.

Why? Because it’s C.

When i’m done with compiling my static cfengine package for archlinux: -rw-r–r– 1 fbettag wheel 447K Jul 22 2011 cfengine-3.2.0b1-1-x86_64.pkg.tar.xz

Yes, you’ve read right. Statically compiled it’s 447K in a .tar.xz, no library dependencies, no nothing. Also, i’ve never seen cfengine eat more than 10MB RAM during Runtime and i never had a box where cfengine crashed or segfaulted.

Admittedly, it is some kind of PITA to get to know Cfengine, i at least spent 24 Hours in migrating my puppet setup to Cfengine, but it was worth it!