Re: Puzzler: Can cfengine replace make?

[Ted Zlatanov]

Steve Traugott <stevegt@TerraLuna.Org> writes:

> On Tue, Nov 06, 2001 at 09:50:05AM -0500, Ted Zlatanov wrote:
>> Steve Traugott <stevegt@TerraLuna.Org> writes:
>> >
>> > Now, here's the question:  Can anyone see a way to do this once-only
>> > type of action cleanly in cfengine?  I've tried several different ways
>> > over the years, but I've never been satisfied with the results.  
>> 
>> I think cfengine can do what you want, but in a different way.  If you
>> set it up right, every time you run it you will get the timezone set,
>> the ntp config file symlinked, xntpd installed, and ntpdate will run.
>
> That is not what I want to do.  One of our 500-1000 line makefiles
> would translate into a *very* long-running cfengine run if written
> that way.

I doubt it would take very long to run.  The complexity in your
makefiles seems to be avoidable with cfengine, IMHO.

> You're talking dozens of installp and rpm executions, as well as gobs
> of miscellaneous things like setting license counts and kernel
> tunables, not to mention the stray filesystem resize operation.  Most
> of these would fail horribly, spewing stderr and non-zero return codes
> left and right, because they only need to be done once.  And it would
> take 15 minutes or more to grind through them all.

Well, obviously you don't want to run certain time-consumptive
commands if they are not necessary.  But you can test whether a
package is installed, for instance, very quickly without actually
installing it and getting errors.  You could put this in a cfengine
module (test & install package for a passed-in package name) and drive
it from there.  Seems like there's a lot of actions in your makefiles
that can be abstracted that way.  Yes, it's 15% more work, but you'll
avoid a LOT of maintenance in the future.

> The 'make' equivalent completes in about 10 seconds if there's nothing
> to do.

Ditto for cfengine, if done right.

> On top of that, that cfengine run would need lots of special checks to
> prevent repeating things which *cannot* be run more than once without
> seriously breaking the machine; installing and configuring HACMP, for
> instance, is not something you want to do more than once.

Again, test & install only if needed.

> As near as I can tell, cfengine works best when your machines are
> starting from an unknown state and you want to do perpetual
> convergence.  It's the computer immunology thing -- assume they're
> likely to get sick, and make sure you have the tools to detect and
> cure them.  At the same time, you need to expect your machines to
> always have a degree of unknown-ness about them, since they started
> from an unknown state -- if you didn't use your management toolset to
> put the bits there, then you don't know what those bits are.  This
> will always make for a small degree of indeterminacy when rolling out
> new patches or applications.
>
> A make-like algorithm works best when your machines start from a known
> state and you want to keep them that way, with a more deliberate
> degree of control over the bits on disk -- you design out the
> unknown-ness.  From an immunology standpoint, this is basically
> genetic engineering.  ;-)  This is an opportunity that only presents
> itself when you are starting from scratch or have the luxury of
> reinstalling existing machines, but it's an opportunity I look for and
> never pass up.  It does not work well when you are starting from an
> unknown state -- go to cfengine.

I don't think machines are ever in a known state, from experience.
Them pesky users get in the way... :)  I think the cfengine approach
is a lot more resilient and productive.

> I understand, agree with, and use this philosophy for things that
> won't impact users or running services.  But you *can't* let a
> management tool install and/or reconfigure critical parts of a 24x7
> machine at any arbitrary time -- there is actually *no* particular
> timeslot you can give it.  The only thing you can do is have some sort
> of once-only functionality, and have things happen automatically when
> the next window of opportunity presents itself, whether that's a
> planned outage or a spontaneous reboot.

Most cfengine actions can be done with an "inform" flag, so they don't
actually perform the action, only inform you of the necessity for it.
I've rarely had the need for that.

Ted