The discussion started with the bug characteristics of v1.2 versus
the trunk.
It seemed from the call that IU was the only institution that can
asses this via MTT as noone else spoke up. Since people were
interested in seeing things that were breaking I suggested that I
start forwarding the IU internal MTT reports (run nightly and weekly)
to the test...@open-mpi.org. This was meet by Brain insisting that it
would result in "thousands" of emails to the development list. I
clarified that it is only 3 - 4 messages a day from IU. However if
all other institutions do this then it would be a bunch of email
(where 'a bunch' would still be less than 'thousands'). That's how we
got to a 'we need a single summary presented to the group' comment.
It should be noted that we brought up IU sending to the 'testing@open-
mpi.org' list as a bandaid until MTT could do it better.
This single summary can be email or a webpage that people can check.
Rich said that he would prefer a webpage, and noone else really had a
comment. That got us talking about the current summary page that MTT
generates. Tim M mentioned that the current website is difficult to
figure out how to get the answers you need. I agree, it is hard
[usability] for someone to go to the summary page and answer the
question "So what failed from IU last night, and how does that differ
from Yesterday -- e.g., what regressed and progressed yesterday at
IU?". The website is flexible enough to due it, but having a couple
of basic summary pages would be nice for basic users. What that
should look like we can discuss further.
The IU group really likes the emails that we currently generate. A
plain-text summary of the previous run. I posted copies on the MTT
bug tracker here:
http://svn.open-mpi.org/trac/mtt/ticket/61
Currently we have not put the work in to aggregate the runs, so for
each ini file that we run we get 1 email to the IU group. This is
fine for the moment, but as we add the rest of the clusters and
dimensions in the testing matrix we will need MTT to aggregate the
results for us and generate such an email.
So I think the general feel of the discussion is that we need the
following from MTT:
- A 'basic' summary page providing answers to some general
frequently asked queries. The current interface is too advanced for
the current users.
- A summary email [in plain-text preferably] similar to the one
that IU generated showing an aggregation of the previous nights
results for (a) all reporters (b) my institution [so I can track them
down and file bugs].
- 1 email a day on the previous nights testing results.
Some relevant bugs currently in existence:
http://svn.open-mpi.org/trac/mtt/ticket/92
http://svn.open-mpi.org/trac/mtt/ticket/61
http://svn.open-mpi.org/trac/mtt/ticket/94
The other concern is that given the frequency of testing as bugs
appear from the testing someone needs to make sure the bug tracker is
updated. I think the group is unclear about how this is done. Meaning
when a MTT identifies a test as failed whom is responsible for
putting the bug in the bug tracker?
The obvious solution is the institution that identified the bug.
[Warning: My opinion] But then that becomes unwieldy for IU since we
have a large testing matrix, and would need to commit someone to
doing this everyday (and it may take all day to properly track a set
of bugs). Also this kind of punishes an institution for testing more
instead of providing incentive to test.
------ Page Break -- Context switch ------
In case you all want to know what we are doing here at IU. I attached
to this email our planed MTT testing matrix. Currently we have BigRed
and Odin running the complete matrix less the BLACS tests. Wotan and
Thor will come online as we get more resources to support them.
In order to do such a complex testing matrix we have various .ini
files that we use. And since some of the dimensions in the matrix are
large we break some of the tests into a couple .ini files that are
submitted concurrently to have them run in a reasonable time.
| BigRed | Odin | Thor | Wotan
-----+----------+----------+--------+------
Sun |N |N | IMB | BLACS
Mon |N BLACS |N |N |N
Tues |N |N IMB* |N |N
Wed |N IMB* |N |N |N
Thur |N |N BLACS |N |N
Fri |N |N |N |N
Sat |N Intel* |N Intel* | BLACS | IMB
N = Nightly run
* = Large runs
All runs start at 2 am on the day listed.
=====================
BigRed
=====================
Nightly
-------
- Branches: trunk, v1.2
- Configurations: All 64 and 32 bit builds
* MX, LoadLeveler, No debug, gcc 3.x
- Test Suites
* Trivial
* IBM suite
- Processing Elements/tasks/cores/...
* # < 8 hours
* 7 nodes/28 tasks [to start with]
- Runtime Parameters
* PML ob1/BTL mx,sm,self
* PML cm /MTL mx
Weekly: Monday 2am Submission
-------------------------------------
- Branches: trunk, v1.2
- Configurations: All 64 and 32 bit builds
* MX, LoadLeveler, No debug, gcc 3.x
- Test Suites
* BLACS
- Processing Elements/tasks/cores/...
* # < 1 days
* 32 nodes/128 tasks [to start with]
- Runtime Parameters
* PML ob1/BTL mx,sm,self
* PML cm /MTL mx
Weekly: Wednesday 2am Submission
-------------------------------------
- Branches: trunk, v1.2
- Configurations: All 64 and 32 bit builds
* MX, LoadLeveler, No debug, gcc 3.x
- Test Suites
* IMB
- Processing Elements/tasks/cores/...
* # < 1 days
* 32 nodes/128 tasks [to start with]
- Runtime Parameters
* PML ob1/BTL mx,sm,self
* PML cm /MTL mx
Weekly: Saturday 2am Submission
----------------------------------
- Branches: trunk, v1.2
- Configurations: All 64 and 32 bit builds
* MX, LoadLeveler, No debug, gcc 3.x
* MX, LoadLeveler, No debug, gcc 4.x
- Trivial only
* MX, LoadLeveler, No debug, IBM compiler
- Trivial only
- Test Suites
* Intel
- Processing Elements/tasks/cores/...
* # < 1 days
* 32 nodes/128 tasks [to start with]
- Runtime Parameters
* PML ob1/BTL mx,sm,self
* PML cm /MTL mx
=====================
Odin (128 dual processor machines)
=====================
Nightly
-------
- Branches: trunk, v1.2
- Configurations: All 64 and 32 bit builds
* No debug, gcc 3.x
- Test Suites
* Trivial
* IBM suite
* Intel
- Processing Elements/tasks/cores/...
* # < 8 hours
* 8 nodes/16 tasks [to start with]
- Runtime Parameters
* PML ob1/BTL tcp,sm,self
Weekly: Tuesday 2am Submission
-------------------------------------
- Branches: trunk, v1.2
- Configurations: All 64 and 32 bit builds
* No debug, gcc 3.x
- Test Suites
* IMB
- Processing Elements/tasks/cores/...
* # < 1 day
* 32 nodes/64 tasks
- Runtime Parameters
* PML ob1/BTL tcp,sm,self
Weekly: Thursday 2am Submission
-------------------------------------
- Branches: trunk, v1.2
- Configurations: All 64 and 32 bit builds
* No debug, gcc 3.x
- Test Suites
* BLACS
- Processing Elements/tasks/cores/...
* # < 1 day
* 32 nodes/64 tasks
- Runtime Parameters
* PML ob1/BTL tcp,sm,self
Weekly: Saturday 2am Submission
----------------------------------
- Branches: trunk, v1.2
- Configurations: All 64 and 32 bit builds
* No debug, gcc 3.x
- Test Suites
* Intel
- Processing Elements/tasks/cores/...
* # < 1 day
* 32 nodes/64 tasks
- Runtime Parameters
* PML ob1/BTL tcp,sm,self
=====================
Thor (8 dual processor nodes)
=====================
Nightly
-------
- Branches: trunk, v1.2
- Configurations: All 32 bit builds
* No debug, gcc 3.x
* No debug, ICC
- Test Suites
* Trivial
* IBM suite
* Intel
- Processing Elements/tasks/cores/...
* # < 8 hours
* 4 nodes/8 tasks
- Runtime Parameters
* PML ob1/BTL mx,mvapi,tcp,sm,self
Weekly: Saturday 2am Submission
-------------------------------------
- Branches: trunk, v1.2
- Configurations: All 32 bit builds
* No debug, gcc 3.x
* No debug, ICC
- Test Suites
* BLACS
- Processing Elements/tasks/cores/...
* # < 1 day
* 4 nodes/8 tasks
- Runtime Parameters
* PML ob1/BTL mx,mvapi,tcp,sm,self
Weekly: Sunday 2am Submission
----------------------------------
- Branches: trunk, v1.2
- Configurations: All 32 bit builds
* No debug, gcc 3.x
* No debug, ICC
- Test Suites
* IMB
- Processing Elements/tasks/cores/...
* # < 1 day
* 4 nodes/8 tasks
- Runtime Parameters
* PML ob1/BTL mx,mvapi,tcp,sm,self
=====================
Wotan (16 dual processor machine)
=====================
Nightly (Not Sat or Sun)
-------
- Branches: trunk, v1.2
- Configurations: All 64 and 32 bit builds
* No debug, gcc 3.x
- Test Suites
* Trivial
* IBM suite
* Intel
- Processing Elements/tasks/cores/...
* # < 8 hours
* 8 nodes/16 tasks
- Runtime Parameters
* PML ob1/BTL mvapi,tcp,sm,self
Weekly: Saturday 2am Submission
-------------------------------------
- Branches: trunk, v1.2
- Configurations: All 64 and 32 bit builds
* No debug, gcc 3.x
- Test Suites
* IMB
- Processing Elements/tasks/cores/...
* # < 1 day
* 16 nodes/32 tasks
- Runtime Parameters
* PML ob1/BTL mvapi,tcp,sm,self
Weekly: Sunday 2am Submission
----------------------------------
- Branches: trunk, v1.2
- Configurations: All 64 and 32 bit builds
* No debug, gcc 3.x
- Test Suites
* BLACS
- Processing Elements/tasks/cores/...
* # < 1 day
* 16 nodes/32 tasks
- Runtime Parameters
* PML ob1/BTL mvapi,tcp,sm,self
Questions? Thoughts?
-- Josh
On Oct 25, 2006, at 8:37 AM, Jeff Squyres wrote:
Looking over Len's minutes from yesterday, I see that there was a
bunch of discussion about MTT on the OMPI teleconf yesterday, but
neither Ethan nor I were there to be a part of it. :-\
I couldn't make much sense from Len's minutes:
-----
- having some trouble with MTT config, so will try to look more
closely at some of these failures
- instead of e-mails sending them to the testing at MTT list
- plenty of internal IU e-mail, better to have one summary e-mail
each day
- cannot send a summary
- send to mtt list and digest it
- or you can just file bugs
- can't use mtt web site to get the info
-----
What is IU requesting? Who can't use the MTT web site to get info?
What info are you trying to get / why can't you get it?
Should we have a teleconf about MTT stuff?
I'm on travel and unavailable all today, but have time tomorrow
(Thurs).
--
Jeff Squyres
Server Virtualization Business Unit
Cisco Systems
_______________________________________________
mtt-users mailing list
mtt-us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
