Luke Kanies wrote:
I actually think problem modeling in the different tools is really,
really interesting.
But actually, problem modeling exists independent of any tool.
I know that the way Puppet forces people to model
problems is different than how other tools would (at least partially
because of the closure work that you did); some of this is really good
and makes for clean configurations, but there are some negative
trade-offs, too. Also, because Puppet can only operate at the level of
resource -- a whole file, a package -- there are yet more tradeoffs made.
I have two "practice" case studies for the group to consider.
Both are about modeling, and both represent workable ways of thinking.
Neither is tool-centered.
a) When I learned about VLANs, I had to completely relearn network
management, because they were so foreign an abstraction. But, as a
result, our network became thousands of times easier to manage.
But it literally took an expert engineer taking me in hand and
training me on how to *think* about VLANs before I could grasp the
impact. Just reading about them in the manual bounced off. And I'm
an *expert* on classical networking. In particular, it was difficult
for me to stop thinking "routers" and start thinking "switches".
The problem was that I was thinking of the switches as boundaries.
A better model of a VLAN-centered network is as a series of
intermeshed *clouds* made each from multiple switches! The hardest
thing to learn in this environment was how the clouds behave. It took
an expert to guide me, change by change, to a new way of thinking.
b) Our staff here has turned use of package management for configuration
management into an art. To accomplish a change, one encapsulates that
change into a package. Most packages are idempotent in the sense that
applying them twice via -force has no detrimental effect. The metric
of success for this is that:
i) When I point out that something is broken, they can fix it in
seconds by forcing a package re-install.
ii) I have to point out that it's broken:)
More important than this, though, is the way they have learned to
interact with the package system. Our configuration management
strategy is 90% discipline and 10% tools. The staff have evolved
a way of *thinking* about configuration changes that keeps them
out of trouble; they know to encapsulate idempotent operators in
packages, which they do with some care.
Now these two cases point out the human condition that pervades our
discipline. I could only adopt a new strategy by being led by an expert.
No amount of reading could make me *think* in a different way.
On the other hand, my staff has a "highly effective" configuration
management strategy for the needs we have. Its only detriment is that
it lacks a monitoring mechanism for feedback. And it is 90% practice,
10% tool base (it is powered by a very short script)!
In both cases, the "rosetta stone" was a way of *thinking* about the
problem that is independent of tool base. While adopting a tool can
be a very heavyweight process, adopting a way of thinking is easier
and often more productive!
--
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
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
