Jeff McCune wrote:
My original post was a request to the Have's; stop for a minute and help
the Have Not's catch up. That's all.
I have been studying this problem for some time. I think it is a real
problem and the biggest part of it is that the systems managed by hand
form a "legacy environment" of which the beginner does not have complete
knowledge.
I have been unsuccessful in interesting any of my students
in solving this problem, alas, because they don't believe that it's
real. They think that if they do come up with a way to seamlessly
move from non-automated management to automated management, they'll
just get crushed by the vendors who'll advocate "replacing everything
with managed hardware", so that the bootstrapping problem will be
moot by the time they have solved it...
What if we could provide a tool to the "have nots" that would allow them
to hit the ground running? I have seen enough "have nots" turn into
"haves" to have some idea of what this thing would do. For one thing,
it wouldn't make people specify policies until it taught them about
their network. Its first phase would be "educational".
e.g., we would never ever conceive of checking global consistency
of large configurations, because that is not a tractable manual
process...
No, but a SA who doesn't have any automated tools deployed can't ever
conceive of this anyway, even though there are tools readily available
to make the problem tractable today.
This is some evidence that we need a very different kind of tool to
transition between manual configuration and automated configuration
than we have now...
But I disagree. We use the trouble-ticket system...
But that's too late... systems are already down...
So if we keep thinking that way, we *can* be replaced
by a computer program that is superior to us simply because
it has a better view of what's going on...
I don't quite understand this example... How does a trouble ticket
system lead to my replacement by C3P0?
The trouble-ticket system is the *only* monitoring that many
sites employ. Machines can monitor themselves better than that.
I'm advocating a different approach. I believe more in the "Keep
evolving the tool(s)... indefinitely" approach which is greatly
benefited by a widely accessible and deployed tool that accepts feedback
and modifications from the community.
As someone who has watched his own sysadmins evolve into using
automation, there are many reasons that this *won't* work.
We are -- in essence -- writing tools for ourselves. Beginning
sysadmins write a very different kind of automation tool than
bcfg2 or puppet. The gulf is not only wide; it's widening; and
I do *not* believe that Puppet and bcfg2 are any reasonable
starting point for the "bootstrapping" problem of getting
someone to "start" using automation.
The bottom line is that they are too dangerous for use by the
uninitiated; and "safety is more important than power" for the
beginner.
Put yourself in the position of a beginner. You're overwhelmed,
your job is on the line, and everything's on fire. And you can
employ tools that with *some* probability, put out the fires,
and with *another* finite probability, make them worse. What are
you going to do? Many people just avoid anything that can make
things worse.
I have advised many people beginning with automation to start
with scripts, evolve into using cfengine, and then evolve into
using bcfg2 or puppet, *knowing* that each intermediate step
is a "throw-away". The intermediate steps are "educational".
--
Dr. Alva L. Couch
Associate Professor of Computer Science
Associate Professor of Electrical and Computer Engineering
Tufts University, 161 College Avenue, Medford, MA 02155
Phone: +1 (617) 627-3674
Web: http://www.cs.tufts.edu/~couch
_______________________________________________
lssconf-discuss mailing list
lssconf-discuss@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
