[TriLUG] Curious

[William Sutton]

Interesting to read this.  I went to a Puppet camp some months ago after 
spending 6 months migrating our CFEngine 2 configuration to CFEngine 3. 
So far that's my only configuration management experience.

The good:
Puppet does guarantee that it reaches a final known (and knowable) state. 
CFE doesn't.  It just keeps rerunning the ruleset until it thinks it got 
the right answer.

CF Engine is client-based, so each machine processes its ruleset, leaving 
the server (policy hub in CFE-speak) relatively bored.


The bad:
CFE and Puppet have similar, but not identical rule language.  Sort of 
like how Perl and C have similar syntax, but not identical.

Puppet is policy-server-based.  For any number of client machines, you may 
have to have a cluster of Puppet policy servers to handle what they openly 
referred to as the "thundering herd" (self-DDoS, if you ask me) problem.

Puppet may have a final dependency list, but as Igor pointed out, you have 
to spell it out in your ruleset.

OTOH, with CFEngine, you may never know if you got there.  CFE keeps 
iterating until it thinks it found the answer--sort of like your co-worker 
who keeps telling the boss something until he thinks he said the right 
thing.

Moreover, CFE evaluates and caches variables.  Sometimes, it doesn't 
evaluate the variable at all.  That's a problem when the variable is used 
in filesystem path expansion.  It's a crisis when it nukes the contents of 
your resolv.conf file.

Also on the minus side for CFE--they routinely have bugs that haven't been 
fixed.  I actually ranted for 5-10 minutes on their Freenode IRC channel 
about how crummy it was, and its biggest supporters, while conceding that 
it was pretty crummy, argued that it wasn't as bad as it could be.

--

I'm going to have to look at saltstack given Matt's high praise.  There 
are some cool looking things about Puppet, but also some things that make 
me twitch a bit.  As far as CFEngine goes, I've seen both v2 and v3 
(which, incidentally, are syntactically different; sufficiently so to hurt 
your brain), and while I can (usually) make it do what I need, it has its 
own deficiencies.

William Sutton

On Sun, 26 Oct 2014, Igor Partola wrote:

> Puppet being morse code centric sounds about right. It is its own language, has its own client/server setup yet can be run without it, has a specific file layout you have to follow... It is confusing and weird. I use it because it gets the job done and because I have not yet figured out how to use Ansible :)
>
> There are some great things about puppet:
>
> - Has basic built in types that are idempotent. This is huge. I don't want to reinvent this, and here Puppet delivers.
>
> - It supports the right built-in types: package, file, service, user, crontab.
>
> - Extensive library of good modules to control things like Postgres, Redis, MySQL, MongoDB, etc.
>
> - It works when done right.
>
> The bad:
>
> - The language is confusing. Includes, imports, etc. suck. Creating dependence is confusing and can be repetitive.
>
> - It is much too slow for what it does. Basic package installation is done one at a time. Some really simple manifests that would take 5 seconds to run by hand, take minutes.
>
> - Too many obscure features. The docs literally have things like "we just released this feature, but don't use it. It's a bad idea."
>
> - Errors cascade, but there is now way to tell puppet to stop on errors. This way if installing MySQL fails, it will attempt to do other unrelated tasks instead of saying "ok fix the MySQL thing first ".
>
> In conclusion, I am not converting any existing projects from Puppet to anything else, but I am looking at alternatives.
>
> Igor
> -- 
> This message was sent to: William <william at trilug.org>
> To unsubscribe, send a blank message to trilug-leave at trilug.org from that address.
> TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
> Unsubscribe or edit options on the web	: http://www.trilug.org/mailman/options/trilug/william%40trilug.org
> Welcome to TriLUG: http://trilug.org/welcome
>