[Infrastructures] Is cfengine a good tool?

Jim Rowan jmr@computing.com
Sat, 22 Feb 2003 23:32:00 -0600


On Friday, February 21, 2003, at 07:33 AM, Tim Writer wrote:

> Jim Rowan <jmr@computing.com> writes:
>
>>
>> They make it way too complicated.  Get cfengine, your favorite shared
>> filesystem, and depot.  Mix and match liberally.  Go at  it.
>
...
> dirty with isconf, I'm a strong proponent of the philosophy.  I've been
> dabbling with cfengine for some months now and I'm still not convinced it'
> s a
> good tool.  Since so many others seem to have a good experience, I'm 
> thinking
> it's me, maybe I just don't get it.

You and several others have posted some good examples of the shortcomings/
annoyances/wierdnesses/etc that cfengine suffers from.  For the most part,
  I don't disagree with any of this -- and I've been through some of the 
exact same issues.  {I didn't get back to the list quickly enough to be 
first, but:} I'll be the first to admit that it has a lot of warts and it 
has a schitzophrenic personality.  [My personal gripe is that it has so 
much magic built in that I am always worrying about it doing something that 
I had no intention of doing. ("if I start using this variable, is it going 
to suddenly think that I want it to start managing the fozbort subsystem?"
)]

Let me draw a parallel: 15 years ago or so AFS came on the scene as a 
global filesystem.  At the time there was nothing like it.  It has some of 
the same characteristics --  (in terms of being "wierd").  However, if you 
wanted to do what it was good at it you had very few choices. (I'm not 
aware of any other choices that were available then.)  Today, it is still 
around and it's still one of very few choices to solve this particular 
problem.  I can't say why there aren't any other choices -- but the reason 
that it has endured is that it's architecture and implementation are good 
enough that it opens a door into another "level" -- enables you to do 
things/go places that weren't otherwise practical/possible -- and the 
result has enough value that it's worth suffering the baggage.

Cfengine is like that.  It's far from perfect.  However, it's good enough,
  and the baggage that it carries is inconsequential enough that (IMNSHO) it'
s a good choice to (be a key factor in helping to) solve the problem of 
managing large numbers of systems.

I introduced it to one place that had 1200+ machines.  Their previous 
operation model was "if something happens to a machine, reinstall it with 
'the image'".  They basically had no capability as an organization to 
change.   Simply adding cfengine to the mix enabled them to start moving.  
Initially it had a very simplistic config, and only managed a few things.  
However, it lived on every single machine and ran every night -- so the 
next time someone said "we need to do xyz", it was quite easy -- whereas 
before it was almost always a big deal -- meaning that a lot of the xyz's 
never happened.

This is why cfengine is so strong -- it enables you to do xyz to all 
(appropriate) machines just by writing some (obtuse:) configuration 
directives/code/statements.  It almost doesn't matter specifically what 
"xyz" is, and you don't have to know in advance what it is -- being in a 
position of being able to do things globally is the key.

[I just made up a metric: the product of the number of machines, number of 
OS's, and the rate of change required.  Lets call it the "infrastructure 
complexity index".]  If your organization operates (or would like to) in a 
mode where this number is high, you *need* cfengine or something like it.  
If it's low, the need for this sort of tool is much less.  [It might still 
be worthwhile, it's just not so clear cut and will depend on other factors.
]

Note that my original statement was "cfengine, depot, and a shared 
filesytem" -- three components.  Cfengine can handle management of binaries/
tools - and it can mitigate the need for a shared filesytem.  In fact, it 
can do a LOT of things.  However, my advice is that you want to pick and 
choose which parts of cfengine you use and which parts of your 
infrastructure are provided by other tools/systems.

That said -- I'd absolutely love it if there were a set of perl modules 
that did (some of) what cfengine does.  However, I don't want to be writing 
perl code to "AppendIfNoSuchLine".  The 'directive' model is one of the 
strengths.


Jim Rowan
DCSI
jmr@computing.com