From: Jeff Squyres \(jsquyres\) (jsquyres_at_[hidden])
Date: 2006-05-26 14:39:48
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).
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
- 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
- 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
perfbase
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?
-- Jeff Squyres Server Virtualization Business Unit Cisco Systems