by In my [last post|https://lopsa.org/node/1903] I gave some first impressions using [bcfg2|http://trac.mcs.anl.gov/projects/bcfg2]. We ended up selecting bcfg2 as our configuration management system for a new project. I’m going to start with the “bad” and get that out of the way.
===The bad===
The biggest problem so far is getting the entire team up to speed on bcfg2. It’s very different from what we’re used to with cfengine2. One challenge is wrapping your mind around what I think is one of the basic tenets of bcfg2 – you specify everything twice. Let me explain: bcfg2 separates out configurations into an abstract specification, and a concrete implementation. For example, you may decide a certain group needs an ”/etc/motd”file. So in the abstract configuration (called a Bundle), you simply say: ”
I’m not saying that this separation of specification and implementation is itself bad – in fact, I rather like it. It’s just __different__, and that makes the learning curve that much steeper. It also leads to some slowness when deploying new Bundles, just because you need to make changes in a couple of different places. With our cfengine2 setup, you just dump a file in the SingleCopy’ed tree and go on.
There are some other small annoyances. One that bit me during our bootstrap process was the order of file distribution vs. package installation. Packages were being installed before the YUM configuration was updated, causing us to get older package installations on the first run of bcfg2. A second run fixed this, but still annoying.
However, this brings me around to a really good aspect of bcfg2 – the developers. These guys are very responsive when problems are reported. I think they sent me a patch to test less than 5 minutes after I asked about the YUM ordering problem.
===The good===
In the bcfg2 world, the server knows all, and the clients don’t know a whole lot. The server parses the configuration and determines which files need updating, which packages to install, etc. This is quite different (again) from cfengine2, where the clients generally parse their own configurations and make their own decisions. The advantage to the bcfg2 approach is that the server really does know everything. For example, I can run ”bcfg2-info showclient bob.foo.com” and see all the Groups and Bundles that applied to ”bob” last time it ran the bcfg2 client. This has been very helpful in debugging problems as we deploy a new infrastructure.
I think my favorite feature so far is ”bcfg2-admin viz”. This command generates graphviz output of the entire Group and Bundle hierarchy, as well as showing which clients belong to which groups. Our plan is to run this as a cron job every hour or so, and have it put the resulting .png onto our documentation webserver. Definitely a handy reference to have around, and awesome that it can be generated so easily.
Another great feature is ”bcfg2-repo-validate”. This command validates your entire repository against the XML schema. cfengine2 had a similar command that would check the syntax of a single file, but nothing as inclusive as this. This will be very handy when we get SVN integration going. We’ll use it to ensure that every checking properly validates.
I’m sure I’m missing some things, but I wanted to get some of this down while it was fresh in my mind.