[Warning for the faint of heart; some plugging of bcfg2 occurs in this mail.]

>>>>> "Luke" == Luke Crawford <[EMAIL PROTECTED]> writes:

  Luke> First off, I'm a "practical" type- a "computer janitor" as it
  Luke> were.  I am also a consultant and an Entrepreneur, so I see my
  Luke> job as eliminating my job- I'm quite interested in
  Luke> configuration management systems, but on a conceptual level, I
  Luke> simply don't understand how they would usefully work.

Do you mean tools at all, or more researchy systems like autonomics
and the like?

  Luke> Now, I see you are speaking of validation tools; This is
  Luke> something I understand quite well, and have implemented
  Luke> (perhaps in a more 'bottom up' than 'top down' fashion than
  Luke> the theory types would have) using Nagios; The idea being that
  Luke> those who consume my services should not need to know my phone
  Luke> number, so my policy is to run an external nagios server to
  Luke> monitor every service I provide to other people.  As I am
  Luke> checking from an external perspective (sending mail through a
  Luke> mail system, or retrieving a html page and comparing
  Luke> known-good bits) the nagios-with-plugin system can catch just
  Luke> about any configuration error the customer can.

  Luke> Now, the problem with this is that it catches the error after,
  Luke> not before the error hits production; as I'm doing quite a lot
  Luke> of work with Xen-based paravirtualized servers, I'm thinking
  Luke> about simply running a full test environment with a duplicate
  Luke> of every real server within my virtual environment; then use
  Luke> some tool (perhaps systemimager? maybe systemimager with
  Luke> service-specific scripts to gracefully reload modified
  Luke> servers?)  to copy configs from test to production after the
  Luke> test passes validation.

We've done a bit of work using staging to catch errors before
installation. We basically could tag new configuration bits as being
in testing, and then the testing systems would get them before the
rest of systems, so that errors could be freely encountered and

Basically what you are describing here is a set of software
engineering/testing methodologies. Our paper at LISA this year
describes a set of slick ways to integrate timeline and versioning
data into configuration management specification, and the things you
can do with this info once you have it. (All implemented with bcfg2,
of course) I would suggest taking a look at it once it comes

We have done a lot of this sort of server replication, now that our
specification is complete. We have found that using the configuration
management system to rebuild a system (upon system disk failure or the
like) is frequently faster and easier than going to backups. Producing
multiple instances of the same service in less tense situations is a
breeze. I would greatly suggest you look at bcfg2 for this sort of

(We've actually use bcfg2 on top of system imager; SI is used for
basic system builds, but all differentiation and updates are done
through bcfg2.)


  Luke> Me, I'm on the list because I'm interested in configuration
  Luke> management; but frankly, my brain it too small to comprehend
  Luke> how you might go about replacing my configuration management
  Luke> duties with a program.  I like the idea, I just don't know how
  Luke> you would do any better than a systemimager style "base image
  Luke> for each class of machine, then per-box lists of diffs to
  Luke> apply"

This is a good illustration of the communication gaps between research
and practitioners. Bcfg2 does a great job of managing a symbolic
configuration for a system in a similar fashion, while allowing much
more fine-grained control over things. Ping me off-list for more
details, if you are interested. 

  Luke> The basic problem that *I* would like the theory people to
  Luke> solve is how to break down the "configure the system"
  Luke> high-level problem into a easy to understand set of tools like
  Luke> nagios that people like me can come in and configure on a low
  Luke> level for each one of our services.  Heck, you don't even need
  Luke> to write the actual tools, just describe what the tools need
  Luke> to do (of course, that's what writing the tools would do,
  Luke> right?  computer languages are designed to precisely specify
  Luke> what a program ought to do.)

I think this also illustrates an interesting point. The theory folks
aren't all that interested in problems at that level. They are a
little past it. Keep in mind that most are working on fields like
constraint solvers, autonomics, etc, and need to publish papers to
maintain good academic standing. Until the tools provide a 
conduit between researchers and our ready users, we will have this
lssconf-discuss mailing list

Reply via email to