On 01/06/07, Narayan Desai <[EMAIL PROTECTED]> wrote:
I also think these sorts of discussions, while quite interesting, put
the cart before the horse a little bit. Luke was talking about
fatfingering configs causing a massive failure. There are two ways to
do this: either causing a failure of core infrastructure in a small
number of places, or causing a per-node failure with a configuration
change or software upgrade. In both cases, a configuration file syntax
error can cause services, persistent or not, to fail. Since this is a
common occurrence, any safety mechanism that we want to be
practical needs to handle this.
Whilst I mostly agree with you, I wanted to point out that failure in
configuration file syntax is markedly less likely if you use templating as
opposed to distributing files as a whole, and that some of the problems you
go on to talk about, e.g. valid IP addresses, valid hostnames, well formed
values, and so forth can be mostly prevented by suitable (and cheap) source
file validation; e.g. regex's on parameter values, DNS and IP lookups at
compile time. This is the approach of both Quattor and LCFG. The overhead
isn't very great because now the values that the sysadmin is changing fall
into a standard format which you can write standard validators for (e.g.
test that this IS a hostname of a host in my system; test that this is a
word with no punctuation in it etc etc). The templates take care of making
sure the tabs are all in the right places and whatever other horridness is
necessary.
...
For this reason, it is not clear to me that this is a practical
near-term solution on Unix systems. As an alternative, we have been
working with behavioral tests, and they provide a much more
immediately useful set of functions. Behavioral tests aren't as
powerful as the analytical ones that Sanjai does, but they sure are a
lot more incremental.
There are problems with behavioural tests as well of course. Not only
are many of the things that you want to test inaccessible from shell script
probes as well, but shell tests inevitably occur after deployment, by which
time it may be too late to undo the damage you caused by doing the change in
the first place, and the question of what to do after deployment fails is a
hard one.
One conclusion I have come to over the last few years is that system
administrators (in general) don't have time in large enough chunks to
readily pursue non-incremental solutions for problems. There are, of
course, exceptions to this, but in general, this seems to hold. I
think that this has pretty big impact on how people adopt tools and
techniques. I would worry that any sort of FOL type system would be
hard enough to deploy and use that it would never make it too far out
of the lab (unless it was completely turn-key, which I gather Sanjai's
tools are)
We agree that average sysadmins writing first order logic is a non-starter.
My concept with cfgw was that someone else (perhaps a single senior
sysadmin, perhaps a tool designer) would write useful predicates which could
then be enabled. This still seems workable to me ("check my systems for this
property, and give me a report") from the perspective of use, but the
technical challenges are a lot harder. Simply put, I don't have time to do
it myself, and noone else seems very interested!
Ed
_______________________________________________
lssconf-discuss mailing list
lssconf-discuss@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
