Wow, that sounds pretty good! How implementable is this, and on what schedule?
-- David N. Lombard My comments represent my opinions, not those of Intel Corporation. >-----Original Message----- >From: Thomas Naughton [mailto:[EMAIL PROTECTED] >Sent: Friday, January 21, 2005 12:27 PM >To: Lombard, David N >Cc: Jeff Squyres; OSCAR-devel >Subject: RE: [Oscar-devel] The Problem With GM > >Dave, > >We chatted with Jeff today about this issue. Here's the summary. > >The current GM OSCAR package (opkg) that grabs the latest greatest does >cause problems as you explained b/c that doesn't necessary (likely) >coincide with the version of GM that was used when LAM was built. And yes >this should be fixed. > >However, the problem is that keeping opkg's (e.g., LAM) in synch with the >ever changing "latest" greated GM release is bad to say the least. The >discussions today centered around the idea of possibly offering better >support for building things from source, where "better" balances: > > (a) Pkg authors: they don't have to rebuild their opkgs all the time, > whenever a new version of GM arrives on the website. > > (b) Oscar users: they don't have to specify every detail about their > cluster and know the intimate details of how to make things work. > >The proposed "ideas" include adding some sort of mechanisms that help to >support package authors building from source, and having the ability to >dynamically determine capabilities such that they can present the user with >"Configurator" options to the User. The user can then either accepts sane >defaults or click a few items and then the necessary steps are taken behind >the scenes such that things are build from source: > (a) in the proper order, i.e., GM build before LAM > (b) configured based upon the dynamic configuration information > (c) build (compiled) > (d) and possibly packaged for pkg mgmt, i.e., create RPM for OSCAR >install > >Another issue with this problem is that you need to have general dependency >information coming into this "Configurator" phase, and dynamic dependence >info coming out of this phase, ex. > (1) [POSSIBLE CONFIGS OPTS] LAM: gm, blcr, ib > (2) [SELECTED CONFIGS OPTS] LAM: gm > >This is necessary so you can do the dependence checks before/after. This >all would have to work with the new "Package Set" idea we've been talking >about lately (this week). > >So....there's really no solutions right now. Hopefully, this helps to >better characterize the problem. I'm not sure what we should do in the >short term but I do think we need better dependence information in the >oscar pkgs, possibly to include the actual oscar-version. > >my $0.25, >--tjn > > > ________________________________________________________________________ _ > Thomas Naughton [EMAIL PROTECTED] > Research Associate (865) 576-4184 > > >On Fri, 21 Jan 2005, Lombard, David N wrote: > >> Having a broken package is far worse than having no package at all. >> >> So, my understanding is that the current OSCAR GM package on OPD will >> legally and properly download the latest GM from Myricom and build it >> properly for the system; the problem being that LAM was built for a >> different GM, and is not expected to work with the latest GM. Is this >> correct? >> >> Is the correct GM available now? If so, can we communicate this >> requirement to the OSCAR GM package? If we do, will that resolve the >> problem? At least for as long as Myricom hosts the correct GM? >> >> If not, perhaps we're making a mistake to consider GM now, especially >> when we consider IB. >> >> -- >> David N. Lombard >> >> My comments represent my opinions, not those of Intel Corporation. >> >>> -----Original Message----- >>> From: [EMAIL PROTECTED] [mailto:oscar-devel- >>> [EMAIL PROTECTED] On Behalf Of Jeff Squyres >>> Sent: Friday, January 21, 2005 9:37 AM >>> To: OSCAR-devel >>> Subject: [Oscar-devel] The Problem With GM >>> >>> So I'm replying but giving this another subject because this is a >>> tangent... >>> >>> What do we want to do about GM? It's actually a problem -- nothing can >>> use GM right now, as it stands. >>> >>> The GM package is downloadable off OPD, and thanks to efforts from >>> Jeremy Enos, it does everything legally -- it pops open a window for >>> the username and password on the Myricom FTP site. Once you enter >>> those, it gets the latest GM source tarball, compiles it, and installs >>> it. >>> >>> However, the GM that LAM was compiled with will almost certainly be a >>> different version (it is now, for certain -- the latest gm in the 2.0.x >>> series is 2.0.17), thereby making it unusable. I don't know how other >>> packages are bundled that use GM, but unless they're updated frequently >>> (which I know they're not), they'll suffer from the same problem. >>> >>> So the issue is that we *don't* have a fixed version of GM, but all the >>> packages that use it will require a fixed version (because things >>> change in each release of GM). >>> >>> Suggestions? >>> >>> >>> On Jan 21, 2005, at 12:31 PM, Lombard, David N wrote: >>> >>>> I've attached a binary rpm audit of the trunk. >>>> >>>> Various conventions are used to partition distro-specific packages. >>>> Should we make this consistent? >>>> >>>> Package-specific comments: >>>> >>>> c3 >>>> -python2 for i386? >>>> >>>> hdf5 >>>> -Huh? >>>> -mdk90 >>>> >>>> lam >>>> -ia64 in rh90? >>>> -gm only for rh90/i386? >>>> >>>> maui >>>> -extra maui-oscar-debuginfo >>>> >>>> mpich >>>> -ia64 in rh80? >>>> -mdk90? >>>> >>>> openpbs >>>> -missing ia64. Do we care? >>>> >>>> perl-qt >>>> -no distro-specific dirs? >>>> -libsmokeqt1? >>>> >>>> pvm >>>> -mkd90? >>>> -mdk92? >>>> >>>> sis >>>> -inconsistent versions >>>> >>>> switcher >>>> -env-switcher only in fedora2? >>>> -mkd90? >>>> -mdk92? >>>> >>>> -- >>>> David N. Lombard >>>> >>>> My comments represent my opinions, not those of Intel Corporation. >>>> <rpm-audit.txt> >>> >>> -- >>> {+} Jeff Squyres >>> {+} [EMAIL PROTECTED] >>> {+} http://www.lam-mpi.org/ >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting >>> Tool for open source databases. Create drag-&-drop reports. Save time >>> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. >>> Download a FREE copy at http://www.intelliview.com/go/osdn_nl >>> _______________________________________________ >>> Oscar-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/oscar-devel >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting >> Tool for open source databases. Create drag-&-drop reports. Save time >> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. >> Download a FREE copy at http://www.intelliview.com/go/osdn_nl >> _______________________________________________ >> Oscar-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/oscar-devel >> ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Oscar-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oscar-devel
