Jeff Squyres (jsquyres) wrote:
> After long interim periods of inactivity, I finally finished at least a
> good chunk of what my to-do tasks were from the IU MTT meeting several
> months ago. I committed r175 earlier today. Specifically:
> - reverse linkage (i.e., later phases refer to prior phases)
> - Trivial modules (testing MPI hello world)
> There is a strong push to start using MTT, mainly for 1.1 release
> testing but also for other reasons. So the question is -- what do we
> need to be able to get a few sites running MTT via cron and dumping the
> results back to a central perfbase? Granted -- MTT is not feature
> complete. There are parts that are not where we'd like them to be
> (e.g., based on what we discussed at the IU MTT meeting). But with my
> commit this morning, MTT should be functional again, so we might as well
> start using it.
> 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.
> 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
> 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?
> - 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.
> - get it all running for ompi members
> - setup production perfbase instance at IU
> - ship a standard starter client config to put in cron to run
> - distribute usernames/passwords
> --> we may not support disconnected scenarios yet; even getting
> "connected" scenarios working will be a big step forward and get us a
> lot of data
> - verify that we can have a 2nd perfbase running for continued
> testing/development/debugging that will not impact the production
We can - just a matter of using a different URL in the client config and
changing some names in the XML.
> 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