From: Jeff Squyres \(jsquyres\) (jsquyres_at_[hidden])
Date: 2006-05-26 15:01:47
> -----Original Message-----
> From: mtt-users-bounces_at_[hidden]
> [mailto:mtt-users-bounces_at_[hidden]] 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