This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
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
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
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?
Server Virtualization Business Unit