Completely unscientific poll: cfengine, puppet, other?

[Christoph Moench-Tegeder]

## Chris Inacio (nacho319 at gmail.com):

> Happy if you would just reply with which one, if any, you use.

I'm using cfengine for a mixed (several Linux, some FreeBSD) environment.
But: without the "cfengine-masterfiles" (available as a port), using
cfengine can be somewhat painful (as already remarked by some); and
when using those masterfiles "as provided" by upstream integration
between the cfengine port and the masterfiles is not really ideal.
Caveat emptor: my cfengine setup did not start with the FreeBSD
machines, some of the problems may be homegrown.

Some items not immediatly relevant to the current question, but perhaps
helpful to to consider when chosing any sort of configuration
management; picked from experience and top of my head:
- what environment do you expect?
  cfengine is C and "data", so there's little inital dependencies
  and you can bootstrap cfengine from a very minimalistic isntallation,
  while puppet/chef/salt/ansible require ruby/python/working ssh/...
  (that alone had been the tipping point in one setup I know of)
  OTOH cfengine/puppet/chef are probably "too large" for embedded/IoT
  stuff - those smallish systems would be fully loaded with the config
  management alone.
- do you want "push" or "pull"?
  Some systems (e.g. cfengine) are using a pull model, where the "managed"
  machines connect to a central hub periodically, fetch the configuration
  and "do what needs to be done", while e.g. ansible follows a "push"
  model, where the "agent" is executed "somewhere" and connects to the
  managed node to do it's work.
  Considerations: network model, load. With the "pull" model, the agents
  are constantly executing, the aggregate load (CPU&IO) may be noticeable
  in virtualized/shared storage environments - and the central configuration
  hub requires enough "horse power" to handle the clients (I've heard of
  problems in that area, and some documentation hits that cascading setups
  should be used for huge setups). Consider having a centralized config
  hub and "change lag" because of periodic polling against "run anywhere"
  and "run anytime you need it".

Regards,
Christoph

-- 
Spare Space