So to clarify - at this point my time (and goal) is to get a nightly
report of whether the three nightly tarballs 1) built 2) passed the intel
and IBM test suites on a couple of platforms. Features like disconnected
scenarios and performance results are important, but are not something I
have time allocated for.
Andy - where are things installed on milliways (both URL and local
On Fri, 26 May 2006, Andrew Friedley wrote:
> 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
> *something* working.
> mtt-users mailing list
Graduate Student, Open Systems Lab, Indiana University