> -----Original Message----- > From: mtt-users-boun...@open-mpi.org > [mailto:mtt-users-boun...@open-mpi.org] On Behalf Of Andrew Friedley > Sent: Friday, May 26, 2006 2:53 PM > To: General user list for the MPI Testing Tool > Subject: Re: [MTT users] MTT resurrected > > > Note that samples/sample.ini is now out of date. > samples/odin.in is the > > most recent and shows all the correct linkage. It can > still be cleaned > > up quite a bit (e.g., Brian was totally unimpressed with > "test build: > > intel", but that very definitely was a test case for my Shell build > > module -- none of that gorp has to be there; it can be > moved off into a > > .pm and hidden behind the scenes). > > Can samples/sample.ini be brought up to date or removed? No point in > having it as-is.
Yes, it can certainly be brought up to date. But I'm turning into a pumpkin for the weekend shortly and wanted to commit stuff so that progress could be made over the weekend. There wasn't time to update sample.ini. I put a note in there saying "don't look here" in case someone does. There's still a lot of good info in sample.ini (e.g., it shows a lot of the &functions that are available); it just has the wrong linkage between phases. > > Brian has been given some cycles by LANL to help get this > going ASAP. > > Andy's only got off-hours time to dedicate to MTT, and as > experience has > > shown, my time available for MTT, while nonzero, is totally > > unpredictable. > > > > Here's the obvious things I see that need to be done: > > > > - verify that the server side of MTT is still functional: > > - is it still running / usable at IU? > > - verify that the code hasn't bit-rotted at all > > - there was a perfbase release this morning; is it worth it to > > upgrade? I saw one or two features that we may care about > > Which features? I'm guessing they're the ones I wrote and sent to > Joachim (xml, multi-line), or was there something else you saw? Yes, those. Are we currently running an SVN version? All things being equal, it might be better to run a stable release (if we aren't already). Easier for Jochim to help us when things break. :-) > > - clear out all previous test data > > - setup a few user accounts for the basic auth > > > > - verify the linkage between mtt client and perfbase > > > > - write some perfbase reports (cron-friendly) for periodic e-mails > > - nightly builds that failed (mpi or tests) > > - nightly test runs that failed > > I think I had mpi install and test build done, will have to look. Ok. > > - verify that we can have a 2nd perfbase running for continued > > testing/development/debugging that will not impact the production > > perfbase > > We can - just a matter of using a different URL in the client > config and > changing some names in the XML. Ok -- the second part is what I'm not clear on. I remember having discussions about the problems of having multiple perfbases running on a single machine since it makes multiple *databases* (not tables) on the server. What names in the XML need to change, specifically? > > Brian's probably got the most cycles to spend on this; > Andrew -- can you > > point him in the right direction for server-side stuff, or > help him get > > it running at IU? > > Yeah, either tonight or tomorrow I'll go take a look at where > I left off > and get in touch with Brian. There shouldn't be much to do to have > *something* working. Excellent. If you could, keep your threads on this list -- when/if I get time to work on MTT, it would be good to be kept in the loop. -- Jeff Squyres Server Virtualization Business Unit Cisco Systems
