>>>>> "Jeff" == Jeff McCune <[EMAIL PROTECTED]> writes:
Jeff> Reading the recent discussions on lssconf, I'm left with the Jeff> notion that everyone seems to have completely missed the boat Jeff> on the real issue. Jeff> First off, site configuration tools don't exist. Really, they Jeff> don't. Tools exist to help a human being configure a site, but Jeff> last I checked, artificial intelligence hasn't yet reached the Jeff> point of being able to do the job any competent SA does. You don't need good AI to do this. I think that LCFG does a quite capable job of allowing you to build rules governing settings that go a pretty good job of handing the case you are describing. Yes, someone needs to set it up, but that is really irrelevant. Jeff> Second, the tools we have configure nothing. We, as SA's Jeff> still configure every aspect of the site, we just use Jeff> *automation tools* to help us do it. The two Jeff> "site-configuration" tools I've used in production; cfengine Jeff> and puppet, are nothing but tools that help *me* automate *my Jeff> own* processes. Jeff> Theoretical discussions are all fine and well, but SA's will Jeff> be paying good money to attend the upcoming workshop. I Jeff> believe everyone involved should strive to help these SA's Jeff> solve the problem they need solved: automating their tedious Jeff> manual processes. That's it. Nothing more, nothing less. You say this as if it is an easy thing to do. Let's face it, you are using puppet because your world view seems to correspond to Luke's. You have a set of tasks and a mental model that are presumably well-served by that approach. This model is not shared by everyone, or even by everyone who is competent. So far, I have found that most good administrators have a mental model of their environment. It is generally well organized, but isn't always structured in a similar fashion. When new folks are deploying bcfg2, I have found that they need to translate their model into the one that bcfg provides. They aren't identical, but at this point I am sure that bcfg's model is sufficient. Jeff> I think you'll find the vast majority of SA's couldn't care Jeff> less about the theoretical items being discussed. They also Jeff> won't care until they've put out the fires that keep cropping Jeff> up... for good. Automation tools help put a fire out and Jeff> prevent it from smoldering. This makes a very good argument for the practice-focused workshop, but I don't think that it argues against the research-oriented one. I know that I have greatly benefited from the ideas at the config workshop, and that bcfg2 would be a far less capable tool without the interactions there. Jeff> If the majority of SA's need help automating the process they Jeff> go through to validate their configuration, then great, help Jeff> them automate validation. If they need help automating Jeff> package installation, that should be a focus. Configuring Jeff> apache? Tools exist to help there. Workstation deployment? Jeff> It's all the same... automate the process. System management software development is hard, for a number of competing reasons. Many administrators are not code-savvy. Many developers are not system-management savvy. These efforts are hard enough that one person cannot reasonably make a serious dent in the problem without help. Most administrators are constantly getting interrupted, so they can't make forward progress enough to make things portable. Jeff> The real focus shouldn't be on what's theoretically possible, Jeff> it should be on what current SA's need to know in order to Jeff> make their day to day efforts more efficient. The solution Jeff> lies in automating their most time-consuming manual process. Jeff> They'll see the light after that. A delicate balance needs to be maintained here. LISA is the main conference where people with the right cross-section of skills congregate. If we venture too far towards either research or practice, either we will make it impossible for practitioners to catch up, or make it so that they stop getting innovative tools a few years out. It is tempting to take the short view, but I think that is problematic. I am pretty skeptical about the bottom up approach that you are describing here; there are some high-level issues that are really important to take into account early. These don't generally get resolved in one-off bits of automation... -nld _______________________________________________ lssconf-discuss mailing list lssconf-discuss@inf.ed.ac.uk http://lists.inf.ed.ac.uk/mailman/listinfo/lssconf-discuss
