From: Andrew Friedley (afriedle_at_[hidden])
Date: 2006-05-26 18:31:21
We've been mostly working out of our home directories. postgres is
installed system-wide, and a newer python is installed in
/opt/python-2.4/bin.
I have a module file for perfbase - milliways:~afriedle/perfbase-module.
Give me a call after 5pm pacific for the postgres password, which I've
just been setting in the environment for perfbase. My home directory
should be open for you to poke around and look at as a reference.
First thing is to set up perfbase - grab the latest release and install
it somewhere - perfbase.tigris.org. Perfbase includes a pair of python
modules that it requires - build/install those, and set up paths to them
as done in my perfbase-module.
Try one of the included perfbase examples to make sure that all works.
There should already be some MTT experiments created in perfbase. They
don't contain any important data, and perfbase will likely complain that
their format is out of date. Feel free to upgrade/blow away as necessary.
Finally, grab MTT svn. The server directory contains all the perfbase
xml, php scripts, and email.pl, which is my cron reporter.
Put the PHP and xml somewhere in your web space. Then take a look at
mtt-config.php and fillin the appropriate environment stuff. We've also
been using .htaccess for authentication.
Unless Jeff has changed the fields again, you should be able to point an
MTT client at the perfbase url you set up and have results go to
perfbase. Expect bugs :)
This should get you started for now.. like I said, I'll figure out where
I left off tonight/tomorrow.
Andrew
Brian W. Barrett wrote:
> 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
> filesystem)?
>
> Brian
>
> 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
>>>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?
>>
>>
>>> - 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
>>>perfbase
>>
>>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.
>>
>>Andrew
>>
>>_______________________________________________
>>mtt-users mailing list
>>mtt-users_at_[hidden]
>>http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
>>
>
>