
Configuration Management Software Sucks - kev009
http://kev.im/configuration-management-software-sucks/
======
shaggy
The main point of the article is true. All configuration management software
is lacking in some regard. However, the article ignores the fact that
configuration management systems are focused on a much wider swath of OS
support than RHEL and Debian based distributions. Most enterprises (and
especially large enterprises) have Linux, Solaris, AIX, HP-UX and Windows that
they need to manage. Managing more than one solution for configuration
management solution is antithetical to a well run infrastructure. The real
problem with configuration management solutions is managing the solutions
themselves. Most of the widely deployed solutions are based on DSLs making the
learning curve steep and the chance for error high. The commercial options
(CFengine NOVA, chef and puppet) all offer GUI based management consoles but
the solutions are expensive for all and often prohibitively so for smaller
shops. It's a crowded space but there is still room for a well designed, easy
to deploy, easy to manage commercial solution that solves these problems.

~~~
kev009
Another commenter here also pointed out Windows and niche Unices. That's
probably more the domain of IBM and CA. Cfengine can do it if you want to put
in the time. But how often does Cfengine come up on this site? It's too barren
by default. A promise lib that targets the EL/Debian majority shop and makes
opinions and assumptions based on the smaller problem set would be welcome by
many. Even if Windows is in play, it's probably self-contained in most shops.
Let the big timers support themselves if you want to unify niche commercial
OS.

~~~
atsaloli
Thanks for bringing up this important area, Kevin. This is a relatively new
and growing field and there is definitely lots of room for improvement.

I was surprised you found "severe incompatibilities" between point releases of
CFEngine 3 -- I've been using 3 since 3.0.2 and have not seen severe
incompatibilities. What did you run into?

Regarding CFEngine being barren by default -- I know what you mean. CFEngine
is a configuration management FRAMEWORK. The CFEngine standard library is an
example of using that framework. It does take a bit of work to use all this,
but once you do, the benefits are enormous (labor and sanity saving, increased
efficiency as a sysadmin, more power over the systems, infrastructure as code,
etc. -- all the usual benefits of configuration management, plus the added
benefits peculiar to CFEngine - support for over thirty operating systems,
small memory and power footprint, very few dependencies and the resulting
ability to run on a very wide range of hardware, from embedded to
supercomputer).

Is there something you want to do with CFEngine that is not in the standard
library? (Please give some concrete examples.) Maybe I could help with that.

I do have over 150 practical examples of using CFEngine 3 at
[http://www.verticalsysadmin.com/cfengine/cfengine_examples.t...](http://www.verticalsysadmin.com/cfengine/cfengine_examples.tar)
and they are all RHEL/CentOS based.

FYI, CFEngine, Inc. grew this year from 4 to 30 staff and are still hiring. I
think you're going to be seeing a lot from CFEngine the company in the near
future.

Incidentally, I'm looking for CFEngine professional service engineers to help
with CFEngine 3 deployments. Details at
<http://www.verticalsysadmin.com/pse.htm>

I'll be training on CFEngine 3 in Palo Alto on January 25-27
(<http://cfengine3.eventbrite.com>), and in Los Angeles on Feb 20-22
(<http://cfengine.eventbrite.com>). Email me for a 10% off coupon.

I also run a free 2 hour webinar "Getting Started with CFEngine 3" - email me
and I'll let notify you of the next one. aleksey at verticalsysadmin dot com

Configuration Management is an actively growing field right now, all the major
players are doing a lot to improve their products. It's going to get better,
stick with it.

~~~
kev009
I believe I started using a 3.x.1 distro package and on the other end a 3.x.5
package if memory serves (this was in April). The minor versions contained
tons additional new features. If there's something 3.x.y can't do that 3.x.y+1
can't do, the middle number NEEDS to be incremented to signify this change.
The promises from the later tail number would not work on the older one.

Some things I think would be useful to ease Cfenfgine adoption:

* _.conf.example files that can be jockeyed around quickly to produce useful working samples within 15 minutes.

_ Specific areas for the above include: installing a file from cfmaster to a
host, installing packages using the native package manager, starting services
using the native service manager

* Reading about promise theory and Cfengine lingo is neat and all but if I'm not convinced of the benefits and have it running in 15 minutes, the install process/doc is flawed. Fixing this will get you much more market share.

* All of the above doesn't mean Cfengine can't handle n-th order complexity and diversity. Instead what I am suggesting is to make it very easy to try on in the simplest cases, and wear well with experience and age in tougher environments.

* Some simple config enumerator scripts. Run yum, dpkg, etc and get a list of all packages. Output this into a config file that the user can edit and put into use right away.

I'll dig through your Cfengine examples some time and see how it's going.

~~~
atsaloli
Thanks for your thoughtful reply, Kevin. I agree with you on the version
numbering, on incrementing the middle number for bigger changes.

I'll talk to the CFEngine, Inc. guys about bundling my example config files
into the package, having simple practical workable examples (that one can
adopt to ones own use) would go a long way in helping people get started.

Agreed we need to improve the whole "up and off the runway" process.

Thanks again for your constructive feedback.

If you have any suggestions on my Cfengine example collection, drop me a line
- aleksey at verticalsysadmin dot com

Best, Aleksey

------
nodata
"All things considered, Puppet is probably the best choice at the moment."

then:

"It sucks, but it’s got a lot of momentum behind it."

And that's his article, basically. Great.

~~~
ericb
Right, that and it ignores chef entirely. Although, even with Chef included,
his conclusion isn't _wrong_.

------
peterwwillis
I agree with the article, and would back up the commenter suggesting OP look
at cdist (<http://www.nico.schottelius.org/software/cdist/>). The simplicity
looks promising.

There is one thing that will completely fix configuration management in Linux,
and that is: all software projects should bundle pre-cooked CM recipes. The
problem of course is which CM tool should they support?

Until one tool ends up winning over all (and it does look like Puppet is in
the lead) we should probably just start a wiki with "community approved"
examples for all popular server software in each CM tool's config language.
With some prodding the 3rd party vendors might just pick them up and package
them, making it a de-facto standard that ships with the distro. Well, one can
dream anyway.

~~~
kev009
I've been playing with Blueprint (which someone suggested on my comments) +
Puppet and am liking this combo quite a bit more than anything else so far.

------
ironchef
Wow. So many things incorrect..let's just look at one. "The set operating
systems used in the enterprise is fairly small: RHEL5, RHEL6, Debian 6, Ubuntu
LTS."

In germany and portions of europe, add SUSE.

In korea, add HPUX.

If you're in pharma or health insurance, add AIX.

Dealing with enterprises in the US? You also need to deal with Windows
environments.

While the problem seems simple, it's extraordinarily complex due to everyone's
environment / way of doing things / "special snowflake syndrome".

Sorry if this seems kurt, but i've had to write commercial software in this
space. You don't want to know how many times I've gotten in arguments with
various enterprises about how stupid is it to do X, Y, or Z. Doesn't
matter...your software needs to support it.

~~~
nigelk
It is easy to fall into the trap of imagining all enterprise environments are
like your own, and even when "special snowflake syndrome" is based on a false
assumption, there are huge differences globally in terms of dominant OSes,
even if you only think about Linux.

The original author is largely correct when it comes to the US in my opinion
though. That subset of OSes does cover the vast majority of US enterprises on
Linux.

------
sciurus
"As a Ruby project, it unsurprisingly has vocal hipster fanboys."

This isn't my experience. Puppet Labs certainly doesn't promote their products
as hip Ruby projects. That would be counterproductive, since their marketing
is aimed at the enterprise sysadmin and his managers.

"in no time flat you’ll start seeing full blown Ruby programs intermingled"

On the puppet-users lists, questions that require writing Ruby are infrequent.
For my repository, the filetype breakdown is

    
    
      $ find puppet/ -name '*.pp' | wc -l
      214
      $ find puppet/ -name '*.erb' | wc -l
      34
      $ find puppet/ -name '*.rb' | wc -l
      7

------
sciurus
The comments about the difficulty of sharing modules rings true. I think the
puppet developers made a mistake by not having a way to separate data from the
"code" as a core, recommended feature early on. Full-heartedly embracing
extlookup a couple years ago might have helped, but that didn't happen either
(see [http://groups.google.com/group/puppet-
users/browse_thread/th...](http://groups.google.com/group/puppet-
users/browse_thread/thread/34e4dfb4828a2835/) for their reasoning).

~~~
nigelk
I absolutely agree.

Not being able to externalize data has had a huge effect upon sharing modules.

Our plan for the next major release of Puppet this year is to integrate Hiera
deeply into Puppet in a more native manner.

<http://projects.puppetlabs.com/projects/hiera>

We're still building out the plan, and will be sending it out to the community
soon for comment, but the basic idea is that parameterized class parameter
lookup will automatically consult a hierarchical store like Hiera if values
are not supplied directly.

Much like Hiera has now, there will also be an easy function to grab arbitrary
data values outside of class parameters.

~~~
sciurus
That sounds great Nigel; I'm looking forward to hearing more.

~~~
nigelk
I can't always map Hacker News personas to people on the list :) so anyone,
please feel free to ping me directly about this sort of thing:

nigel@puppetlabs.com

------
olegp
I found all existing configuration management systems to be overly complicated
and not modular enough.

So, I've decided to try and reinvent the wheel with Bootstrap:
<https://github.com/olegp/bootstrap>

Any feedback or comments would be really appreciated.

------
zzamboni
Kevin, thanks for pointing out many truths about the current state of
configuration management. It is indeed a very important topic.

(disclaimer: I work at CFEngine AS)

I agree that there is definitely room for improvement in all the configuration
management solutions, although all three major players (CFEngine, Chef and
Puppet) have made great progress. For a good overview, I recommend reading the
excellent series of articles posted recently by Sean OMeara from Opscode:
[http://blog.afistfulofservers.net/post/2011/12/30/cfengine-p...](http://blog.afistfulofservers.net/post/2011/12/30/cfengine-
puppet-and-chef-part-1)

CFEngine 3 has been built with the intention of lasting for decades - as a
framework more than a pre-built solution. You mention that "A configuration
system should be opinionated", and I fully agree with you. This is one of the
reasons reason why I like CFEngine: it is _strongly_ opinionated, and those
opinions are based on years of experience and careful thought about the
problems of configuration management. You can twist CFEngine's metaphorical
arm and have it do anything you want, but life is much easier if you learn to
"think in CFEngine" and appreciate all the work that it does for you behind
the scenes. Things like normal ordering
([https://cfengine.com/manuals/cf3-reference.html#Normal-
order...](https://cfengine.com/manuals/cf3-reference.html#Normal-ordering))
and the lack of explicit flow control constructs
([https://cfengine.com/manuals/cf3-reference.html#Loops-and-
li...](https://cfengine.com/manuals/cf3-reference.html#Loops-and-lists-in-
CFEngine-3)) are the result of distilling configuration management to its
basic concepts, and building a tool based on them.

I should mention, because it seems to be a common misconception, that CFEngine
3 is a completely new and different beast than CFEngine 2. The policy language
was completely redesigned, and is now much more extensible, generic and
flexible. With CFEngine 3, you can have a top-level policy that says "build me
a datacenter", building upon lower-level policies that take care of different
components, down to the lowest level where the actual implementation takes
place (package installation, editing files, setting permissions, creating
users, etc.)

As a framework, CFEngine requires a larger initial investment in time, but
once you put in that time, you have a system that allows extreme flexibility
and scalability.

Having said this, it is indeed true that there needs to be a good collection
of higher-level components that makes it easier for users to get started, and
to get a good feeling for the power of the tool. We are working on some ideas
and infrastructure that will allow us to address this problem, and on
improving the standard libraries (which, by the way, are included by default
with CFEngine). The guys at Chef have also done an excellent work in this
respect, and you can see a lot of pre-built cookbooks at
<http://community.opscode.com/cookbooks>.

However, the devil in the details! It may be true that "the set operating
systems used in the enterprise is fairly small: RHEL5, RHEL6, Debian 6, Ubuntu
LTS", but how about the parts that aren't? And even then, those operating
systems are used in an infinity of configurations, architectures and layouts.
You want a configuration management system that is able to manage 100% of your
infrastructure, and this is where the low-level control that you get with a
tool like CFEngine gives you a lot of power: you can use the higher-level
components for those systems that match, but you can also drill down to
specify the details that are necessary for those systems that don't. Plus
CFEngine runs literally everywhere - we showed at LISA'11 a proof of concept
of CFEngine running in an embedded device, it runs on anything that has a
Unix-like operating system, including cygwin under Windows (the commercial
version has native Windows support).

Also, CFEngine has a fantastic user and developer community. I invite you to
drop by the forums (<https://cfengine.com/forum/>) if you have specific
questions or comments about the tool.

And finally, a shameless plug: my book "Learning CFEngine 3" from O'Reilly is
now in Early Release (final version will be out around March). All the
examples from the book are available at <http://cf-learn.info/code.html>.

~~~
kev009
Yes, I bought your ebook last night pre-rant and gave it a quick once over.
It's was pretty low level. I hope you might consider adding some labs at the
end to tie it together at some point.

Cfengine looks like it's in for the long haul. I think with a proper framework
it would even be useful in the single rack applications I desire. Think Ruby
on Rails vs. roll your own everything. That's what I'd like to see on top of
something like Cfengine.

~~~
zzamboni
Thanks for the feedback on the book. If you have any detailed comments, please
let me know, preferably over at <http://cf-learn.info/discussion.html>.

CFEngine is definitely in for the long haul. There are many users of CFEngine
that have built and manage complex infrastructures using it, and have built
their own high-level components. We are now starting a more organized effort
to bring more of these components to the community.

