Sanjai Narain wrote:
Hi Luke: The new session is intended to focus on practice as well. Since
the vast amount of configuration today is manual, large numbers of
configuration errors are made. So, tools to diagnose these are of
substantial practical use. I am referring to errors that cannot be
diagnosed by a simple "diff" between a golden state and the current
state. Rather, these are deep structural errors that violate end-to-end
security, connectivity, performance and reliability requirements.
Diagnosing whether these requirements are falsified cannot be done
locally by examining each component in isolation. Rather, it needs a
global approach where we check -relationships- of configurations of
multiple components. A new class of algorithms needs to be developed
that is analogous to those for static analysis of programs.
For example, suppose one asks whether there is a single point of failure
in an infrastructure. How does one answer this question? Surely not by
failing each component and checking? This is a hard problem because
spofs can arise at each layer, and at each layer there can be both link
and node failures; even if each layer does not have a spof, incorrect
mappings between layers can creat spofs; fault-tolerance
misconfiguration can cause service to not recover even if redundant
resources are available; finally, interactions between security and
fault-tolerance technologies can arise. By examining component
configurations, one can create pretty penetrating answers to this
question. -- Sanjai
Narayan is right -- I'm more concerned about practical usage by a larger
set of sysadmins.
This is a perfect example -- the vast majority of sysadmins I know have
little or no automation in place and don't know how to use available
tools to make their lives easier; they're certainly not going to be able
to use a tool to do automated analysis of their network. Heck, they
don't even usually have any idea what their network is supposed to even
look like, much less be able to verify it. I blame this lack on both a
paucity of good tools (which both Puppet and BCFG2 are doing a much
better job of addressing, I think) and on a lack of attention paid to
how these tools can help.
It seems like this workshop is about 10 years ahead of reality, and I
don't think it's being as productive as it could be. I understand that
there's a desire to spend a lot of time on theory, and I think that has
its place, but I think it's also important to spend some time on
reality, and acknowledge the current state of the sysadmin world. Are
we any further than we were last year, where almost no one in the room
could recommend a tool for sysadmins to use? Everyone hated cfengine,
but no one was really willing to stand up and say, "X is what people
should use."
This is why I recommended splitting the workshop into practice and
theory. I want a workshop for people who want to have a tool that can
be recommended to sysadmins. I don't particularly care about the theory
except as it impacts my ability to make a better tool, and I expect that
we need to be wrong a *lot* more often before we'll have enough data to
creaet good theory.
I'm just at the point where I can't really find the theory interesting
until we've got more data, and the only way I see of getting data is to
get tools out there and in use. Science is about coming up with
theories to fit the data, not the other way around.
Is there a plan to have anyone talk about BCFG2 and/or Puppet and/or any
tool that an average sysadmin might use, such as what their
implementation and/or use has taught us? Have we learned anything? Do
we even know?
I've got a Puppet workshop scheduled for Sunday, and seeing as how I'm
the workshop coordinator, I might just change that to Practical
Configuration Management, or Configuration Management Tools, or
something like that.
--
There is no expedient to which a man will not go to avoid the labor
of thinking. --Thomas A. Edison
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
_______________________________________________
lssconf-discuss mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
