Alva Couch wrote:
Jeff McCune wrote:Theoretical discussions are all fine and well, but SA's will be paying good money to attend the upcoming workshop. I believe everyone involved should strive to help these SA's solve the problem they need solved: automating their tedious manual processes. That's it. Nothing more, nothing less.That assumes that "what we now do" is "what we need to do."
Yes, it does. I strongly believe "what we do now" should be "expose more people to what we do now."
The Have's are presently using some form of automation tool to help them configure their large site. The Have Not's are using no formal automation tools.
In my experience, the Have's are relatively few, and the Have Not's are the overwhelming majority. I'd bet they're in the 99th percentile of SA's employed today.
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.
Debating if the Have's are doing "what we need to do" with their toolset isn't productive in my mind. We already have tools that greatly increase our efficiency on the job. The problem, as I see it; virtually nobody uses those tools except a very small group of people.
Consider another possibility; Instead of endlessly debating the pros and cons of one existing tool versus another existing tool, and the super-high-level features of each that *nobody* (from a global perspective) really uses, we redirect our efforts to educating and empowering the rest of the community on the existing tools we rely on now.
In this situation, a tool that's open and backed by a development group that willingly works with the community will naturally evolve into what it needs to be. In effect the "what we need to do" will naturally develop itself.
I tend to disagree. In fact, I think that if we continue to think that way, the autonomics guys *will* replace us with computer programs:) The idea of defining configuration management as automating manual things is compelling and tempting. But if we actually solve that problem, that will not solve the problem of configuration management completely. If we constrain ourselves solely to automating manual processes that exist now, we also constrain ourselves to the limits of those existing processes, which are constrained by what a human can accomplish, not what a machine and a human together can accomplish.
I agree with you, configuration management is much more than simply automating manual processes a human performs. My argument; the end goal is unreachable and unimportant until a viable path to it is available to the community at large.
However, the reality of the situation today is that virtually nobody (except perhaps the admins at Google, or Amazon) is ready to take the leap in abstraction you and many on this list are constantly discussing.
Practically speaking, a workshop should empower the attendees rather that just leave them with a sense of "Wow, that's really neat, but there's no clear path from where I'm at now to where they're talking about going."
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.
Therefore, I believe the focus of the workshop should be improving the path from no configuration management to the ultimate goal of enabling the management of otherwise impossible tasks.
One step at a time though... The community at large won't care about checking global consistency of large configurations until their current fires are put out for good and they understand basic automation best practices.
But we don't do that now, you say...
A very select few perform global consistency checking now and other super-high-level management strategies. I'm one of them. The overwhelming majority do not and cannot until their immediate fires are extinguished and *stay extinguished*.
As a result of this division, there's not many people I can talk to any more about system administration. This saddens me because I have a lot to share and a lot to learn.
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?
So if we define "practical" as "bottom-up", we may close the door on ways tools can serve as a lens with which we can view our systems, in ways that there is no reasonable technique for accomplishing manually.
Yes, but if we don't define practical as bottom-up, we *are* closing the door to the overwhelming majority of system administrators who have immediate problems to solve.
I believe closing the door on so many people will yield a far blurrier lens than anything a select few will come up with after endless mailing list debates about super high level abstractions only applicable to a very few number of SA's.
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.
Until we have tools that are widely accessible, we have nothing but theoretical debates about things virtually nobody will use. That's what I call wasted effort. We can do so much better.
All the best, -- Jeff McCune The Ohio State University Department of Mathematics Systems Manager
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ lssconf-discuss mailing list lssconf-discuss@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
