I’ve spent right at a year of off and on work on my Bcfg2 project to replace my custom configuration scripts/tools with a real tool.  I’ve had lots of good progress, especially with being able to write additional plugins to integrate it very seamlessly into the environment.  Bcfg2 is a fantastic tool in many regards.

However, I’ve run into some design issues and am not sure what to do next.  Right as I’m starting to see the finish line in sight as well.  Bcfg2 and I don’t get along with our RPM package management techniques.  I have to handle several advanced RPM packaging concepts.  The KMODv1 and KMODv2 kernel module packaging standards as well as the IUS packages that are named” php53” and “php53-mysql” and the like.  So, no screwing around with bad RPM calls.  The only way to properly handle packages and their dependancies is with Yum.

One of the design goals of Bcfg2 is that it can know every package that should be deployed on your machines and can remove the rest.  I can’t argue with that as there are folks that need to use a configuration management tool in such a way.  My goal, however, is to specify a base set of packages/configuration and ignore the rest.  Bcfg2 supports this as well.

In the Bcfg2 server I’m using the Packages plugin.  Its a new-ish plugin that takes the packages I have included in my specifications, pulls down the Yum metadata from configured repositories, and tries to ferret out a closed list of dependencies.  (Compared to having to specify a full list of packages.)  The packages I specified and the found dependencies are shipped off to the client as a list of packages to verify/install.  The Bcfg2 server’s Packages plugin is doing this internally and not using Yum.  That’s probably the correct behaviour as the server should be able to run on hosts that Yum does not support (like Debian) while still supporting CentOS or RHEL clients that do use Yum.  In reality a set of packages possibly including virtual provides, and just simply wrong dependencies are sent to the client.

The Bcfg2 clients have a Yum driver that pipes the package list through the client’s local Yum setup.  Yum doesn’t verify packages well (the yum-verify plugin wasn’t any help either) so that functionality is shunted to the RPM driver to verify a specific package is intact with only Bcfg2-known changes.  (Normally, this works pretty well.)  I’ve recently patched the Yum driver to deal better with virtual provides (used in the KMOD standards and elsewhere) but Bcfg2 doesn’t have the needed information to chose between the multiple packages that may match the virtual provides or handle the IUS packages.  That’s a job for Yum and Yum proper and that forbidden knowledge should not be in Bcfg2.  So how does Bcfg2 figure out what package to verify?  I gave it some more general clues which help, but it still does a bad job of it.  Worse, if the wrong guess is made and that package does not verify, Bcfg2 turns around and tries to (re)install it.  So effectively, Bcfg2 sees all my test systems as “dirty” because it has assumed it knows better than Yum and possibly told the machines the wrong packages to install or to check packages that need not be in the specification.

What do I expect?  I expect to list packages in my specification that should be installed (say “openafs-client” in the AFS Bundle).  I expect the Bcfg2 client to confirm that “openafs-client” is installed via Yum and that Yum will ensure all the dependencies for “openafs-client” are installed as well.  Including the kernel module which Yum knows how to chose.

The real question is how do I fix this?  Bcfg2 needs to be able to specify the entire package set if the admin wants to go that route, but it also needs to handle enforcing a small subset of packages correctly.  A new server plugin that doesn’t attempt to resolve dependencies?  A way to get Yum to resolve and verify a specific dependency string?  Somehow rigging up the server to be able to fully depsolve for the client using Yum?  What’s the right way?