in DevOps

Crazy … bcfg2 for netapp?

While talking with Tom, it struck me that we could use bcfg2 to manage
our filer configs. Filers are basically a bunch of files with some
sort of way to trigger a re-read. If we mount the /etc dirs of a filer
on the management node and run bcfg2 in a chrooted environment against
that directory structure, we get “instant” manageability of the config

A few custom actions that fire off when the config files change and we
have something we can use to better enforce policy on the filers. And
we could build up a fake filer using the Netapp emulator to act as a
test environment.

Of course, two things occur to me after talking with Narayan about it.
I’m now a bit deflated that someone already thought of doing this (though
with VM images and read-only netboot systems). Second, I think someone
would chase me around with a baseball bat if we actually went through
with this.

Nonetheless, it was a fun thought experiment. Just thought I would
share. 🙂

“The distance between insanity and genius is measured only by success.”

Travis Campbell
Staff Systems Engineer at ghostar
Travis Campbell is a seasoned Linux Systems Engineer with nearly two decades of experience, ranging from dozens to tens of thousands of systems in the semiconductor industry, higher education, and high volume sites on the web. His current focus is on High Performance Computing, Big Data environments, and large scale web architectures.
  1. Very interesting approach. Do you find it often that you need to push site-wide config bits to all n number of filers? Or are most of your configuration changes atomic wrt yay on filer n, nay on filer n+1, etc?

    Also what made pick bcfg2 and not the smattering of other cfgmgmt solutions out there?

    Cheers from

  2. @Nick:

    It’s not uncommon to have to do this. We built a platform for doing this at AMD with just a bunch of make files for some of the more common files (snap mirror stuff, for example).

    The bigger reason to do this is to enforce consistency and regularize the change management process. If everyone plays by the same rules, it makes it easier to understand what’s going on with the systems in the long term.

    DFM sort of provides the capability to do this for you, but it was very onerous and was more for auditing the correctness of configurations vs having long term change management and logging of changes.

    bcfg2 was here before I arrived. I believe cfengine and puppet were also evaluated but this one won out because of features and usability. I don’t have any of the details really. Coming from a cfengine background, it takes a 180 degree shift in ideology to understand bcfg2’s “define the end state” vs cfengine’s “define the path” mentality.

    I’ve come across cases where I wished bcfg2 had the ability to just define the path, especially for events that only ever need to be run once on a system (eg, configuring LVM for my MySQL partitions).

Comments are closed.