I agree with Neil. Our solution specialists have had a fair amount of contact with HPC customers at all levels (small to whopping clusters) and they are more in favor of the "pretty" interface.
My personal take is that there may have to be more than one way to accomplish the installation. For the smaller clusters (up to 128/256) maybe we have a fancy interface approach. If I can supply you with a list of MAC addresses from the supplier (not an unreasonable request), this should work well with the current type of interface. For the REALLY big clusters the command line may be the only way. In other words, one size may not fit all. In any case, we need to have a "low touch" approach. Set up the master, give it the list of MAC addresses or let it discover them for itself, install the nodes in turn by connecting the power and enet (faster interfaces if needed, but initial load is over enet), turn on the power and walk away. The rest should be automatic. We have the technology to do it. Tom Lehmann - Intel -----Original Message----- From: Neil Gorsuch [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 05, 2003 12:19 PM To: OSCAR development Subject: Re: [Oscar-devel] Rewriting the installer I'll take a GUI installer with pretty features (and messy code behind it), over a less functional GUI installer that follows a sequence/model shared with a CLUI installer (with well architected code) any day. So will the vast majority of OSCAR "customers". You're fooling yourself if you think that this won't impact OSCAR "sales". At 08:31 AM 3/5/2003 -0500, Jeff Squyres wrote: >Short version: >============== > >I think that in order to progress OSCAR, we need to re-write the >installer. I am *not* in favor of "fixing" what we have -- I think >the effort would be the same to a) fix what we have, or b) re-write it >with a solid design. > >Let's also remember that as the OSCAR working group, it's our *main >job* to concentrate on the *functionality* of OSCAR, not necessarily >how pretty it looks. Of course it should be professional and >functional, but "pretty" should definitely be a secondary concern. > >I'm not tied to MetaMenu -- if MM is not "enough", then let's do >something else. Other proposals would be appreciated. > >Longer version: >=============== > >What we have needs to be redone >------------------------------- > >For anyone who has looked at the installer code, you know it's a pile >of junk. It's functional, yes, and it does a reasonable job, but it's >hack upon hack upon hack upon hack. It was written in the "pile of >mud" design philosophy -- little pieces were added here and there over >time until we have what we have now: a large, complex, heavily >inter-related chunk of code. > >This makes the code difficult to maintain, difficult to extend, and >difficult to progress -- mainly because there is no overall design. >Hence, there is little modularity, and different pieces of the >installer unexpectedly depend upon each other (leading to cascading >failures when you try to modify something). Some parts are better / >more modular / more robust than others, sure, but that's not the >point. > >The point is that there's no overall design. NCSA has (righfully) >complained multiple times about the lack of documentation about >Package.pm (and friends). Everything is done in an ad-hoc manner, >sometimes (usually?) without regard to the overall system. > >For this very reason, I do not believe that moving towards a simpler >interface (GUI) is "moving backwards". The drawbacks of our current >system are *so severe* that if we have a simpler interface system, the >benefits (in terms of functionality -- our main job) greatly outweigh >any drawbacks of having a simpler interface (GUI). > >So "fixing" what we have (IMHO) is not workable. What we have is so >broken that "fixing" it would essentially be re-writing it anyway. So >my proposal is to shed the pretense of "fixing" the current stuff and >re-write [essentially] from scratch. > >If we can agree on that (or at least take that as a premise for the >rest of my discussion below, even if you don't agree :-), the questions >become: how do we re-write it? > >Professional, not [necessarily] pretty >-------------------------------------- > >Before attempting to answer that question, I think some of us have >lost sight of our ultimate objective: to make Righteous, Dang-Blasted, >Awesome Cluster Code (RDBACC). Of course it has to look professional >and be functional to novice users. But it also has to work for >advanced users (e.g., why we need a real CLUI interface). > >Our funding streams are all tied to getting *funtionality* -- adding >featues and making RDBACC. And I was somewhat serious yesterday when >I said on the call that none of us have the expertise to make "pretty" >looking applications. It is really not worth our time to design >sophisticated GUI applications with glitz and animations -- nor is it >our charter / mandate. That is *NOT* the point of what the OSCAR >group is for. > >For example, what is more important: having a button line up exactly, >or having the ability to use a password for MySQL ODA databases? One >directly impacts security, the other is glitz. I think the choice is >clear. > >And remember that having a CLUI interface (or XML or ...) would >[potentially] allow someone to write glitz on top of the installer. >Someone more qualified than us, and someone who has the time and >resources to do it. > >I'm *not* saying that we don't need to worry about the presentation of >OSCAR. Of course we do. Of course we have to have a >professional-looking installer (and I challenge anyone to say that the >one we have now is professional looking -- look at the logo again and >try to defend that position :-). Of course we need to have it "easy >enough" to use for novice users -- that's the goal of OSCAR, after >all. > >What I'm saying is that we should be channelling the majority of our >efforts into cluster-based functionality (RDBACC), such as the >ambitious designs and goals that we outlined at the IU meeting. The >interface will follow, and it will be reasonable, professional, etc. >But worry about functionality first, or the whole interface issue >becomes moot. Simply put: why argue about interface before we even >have the functionality? Doing so will lead into a tar pit, and we'll >never get the functionality for fear of not being able to support >amorphous, arbitrarily complex vaporware GUI's at some point in the >indeterminate future. > >MetaMenu and others >------------------- > >MetaMenu was conceived to be a simple solution to this problem. I do >*not* believe that MM is the be-all, end-all solution. It was >envisioned to be a fairly simple answer that provided the >functionality that OSCAR needed, but did not try to be glitzy. > >As I tried to make clear on the call yesterday (and in all previous >discussions of MM): > >- it definitely entails re-writing much/most/all of the current > installer in terms of MM states >- it will not be a glitzy solution >- its benefits outweigh its drawbacks > >When we started talking about this last October/November, I trolled >around on the web and talked with Sean Dague (who knows much more >about this stuff than I), and we pretty much came to the conclusion >that there wasn't any other tool out there (currently) that did what >we needed it to do. Hence, MetaMenu was born. > >But if it's not "enough" -- fine. Let's do something else. I have >zero problems with that. But let's do the Right Thing, not a >GUI-based solution solely for the sake of glitz. > >But also remember: if you accept the premise that we have to re-write >the installer, then *anything* that we do will be expensive in time >and resources. So MetaMenu is potentially no worse than other >proposed solutions. > >How to proceed >-------------- > >So back to the question posed above: how to re-write the installer? > >First off: we really need to have a real design. I'm fine with rapid >prototyping (after all, we *are* only talking about several thousand >lines of code, so OSCAR is "large" but nowhere near "huge"). But >there should be *some* overall plan and adherance to developer style >and guidelines. > >To that end, I'd like to make a first stab at requirements (these were >actually what I had in mind when I designed MM): > >- able to run in a variety of environments (text-based, CLUI, GUI, > etc.) >- completely separate functionality from presentation >- support a fully modular design such that adding a new installer step > "in between" two other steps is not difficult >- able to provide stable yet flexible ordering of modules (installer > steps) such as pre- and post-requisites, etc. >- allow arbitrary code to be insertted at any point in the process > >(donning flame retardant suit) > >Comments? > >-- >{+} Jeff Squyres >{+} [EMAIL PROTECTED] >{+} http://www.lam-mpi.org/ > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >Oscar-devel mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/oscar-devel ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Oscar-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/oscar-devel ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Oscar-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/oscar-devel
