[MTT devel] No toggle for running autogen.sh in GNU_Install?
Would it make sense to add a "run_autogen" boolean parameter of some kind for GNU_Install.pm? Or is there a reason the autogen step has been left out for this Install plug-in? -Ethan
[MTT devel] Why does OMPI.pm do a Copytree before it installs?
Why does Install/OMPI.pm "cp" all the sources to another directory before building it? ... Evaluating: require MTT::Common::Copytree Evaluating: $ret = &MTT::Common::Copytree::PrepareForInstall(@args) >> copytree copying to /installs/XfxU/src Copying directory: /sources/mpi_get__ompi-nightly-trunk/trunk Running command: rm -rf trunk Command complete, exit status: 0 Running command: cp -r /sources/mpi_get__ompi-nightly-trunk/trunk . ... The above happens with or without --force. Wouldn't it be more efficient to just have one set of sources and configure using --prefix? -Ethan
Re: [MTT devel] First cut at MTT web pages
On Thu, Sep/06/2007 08:35:01AM, Jeff Squyres wrote: > I put up a skeleton of the MTT web pages on the OMPI web site, but > didn't link to them from anywhere. This actually involved changing a > bunch of infrastructure because we published the name /projects/mtt/ > in the paper but PLPA was under /software/plpa/. So I had to move > PLPA to be under /projects/plpa/etc. You probably don't care > about the details. ;-) > > Anyway, /projects/mtt/ now exists and has skeleton content. I even > put up dummy tarballs (that are empty). Two things to note: > > 1. There are 3 places where I have links to MTT content on the OMPI > web site. If you are in a personal checkout (i.e., if the first two > chars of REQUEST_URI are "/~"), the links will show up and be noted > with "(FIX)" in red. If you're on the live OMPI web site, the links > don't show up (yet). > > 2. Our OMPI MTT testing results are in /mtt/ -- the MTT project site > is /projects/mtt/. This actually creates a problem for the left-hand > navigation scheme because it looks at the basename of the subdir to > know when to print the sub-menus. For example, if you view a > personal checkout and go to /projects/mtt/, you'll see the MTT > project sub-menu listed twice on the left. I could add a hackaround > in the PHP of the OMPI web site, but thinking about it a little, I > wonder if it would be better to simply move the OMPI MTT testing > results to /testing/ (with an appropriate apache-level redirects left > at /mtt/ so that all old permalinks and whatnot continue to work). PHP issues aside, I think having these two is confusing: http://www.open-mpi.org/mtt http://www.open-mpi.org/projects/mtt Nothing in the first link indicates test results (that was something I liked about "reporter.php" :-)) So yes, I favor renaming mtt/index.php. > We'll need to get everyone to update their client INI files, though > -- I'm not sure that LWP will understand a POST redirect...? Can't we move mtt/index.php to mtt/results/index.php or mtt/testing/index.php (I prefer "results"), and leave mtt/submit/index.php alone? -Ethan > > Comments? > > -- > Jeff Squyres > Cisco Systems > > ___ > mtt-devel mailing list > mtt-de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
Re: [MTT devel] [MTT users] Test runs not getting into database
For now I put a quick hack in the /l/osl/www/www.open-mpi.org/mtt/
config.inc file to allow this specific BigRed server to submit. This
will bring the BigRed runs back online until one of you can fix the
mirror/mpi-relay issue.
<->
[jjhursey@milliways mtt] svn diff
Index: config.inc
===
--- config.inc (revision 721)
+++ config.inc (working copy)
@@ -3,18 +3,23 @@
# Open MPI-specific functionality: deny mirrors access to Open MPI MTT
$mother_site = "www.open-mpi.org";
$server_dir = "/";
+# JJH: Hack work around for BigRed which uses the mtt-relay and
reports the
+# JJH: following name. This should be fixed by fixing the mtt-relay
+$iu_bigred_site = "s10c2b3.dim";
# Are we the "mother site" or a mirror? Remember that "alerts.php" is
# run locally as a script via cron, therefore it won't have certain
# array keys set in $_SERVER (and therefore should not be subject to
# the mirroring stuff).
if (array_key_exists("SERVER_NAME", $_SERVER) &&
-$_SERVER["SERVER_NAME"] != $mother_site) {
+(0 != strncmp($_SERVER["SERVER_NAME"], $mother_site, strlen
($mother_site)) &&
+ 0 != strncmp($_SERVER["SERVER_NAME"], $iu_bigred_site, strlen
($iu_bigred_site)) ) ) {
$equiv_dir = ereg_replace("^$server_dir", '', $_SERVER
["REQUEST_URI"]);
print "Sorry, this page is not mirrored. " .
"Please see the http://$mother_site/$equiv_dir
\">" .
"original version of this page " .
-"on the main Open MPI web site.\n";
+ "on the main Open MPI web site.\n".
+ "DEBUG [".$_SERVER["SERVER_NAME"]."] != [".$mother_site."]
\n";
exit();
}
[jjhursey@milliways mtt] pwd
/l/osl/www/www.open-mpi.org/mtt
<->
-- Josh
On Sep 6, 2007, at 10:25 AM, Josh Hursey wrote:
(Off Users list for the moment)
A bit of debug output:
$_SERVER["SERVER_NAME"] = s10c2b3.dim
$mother_site = www.open-mpi.org
So it looks like the relay is doing something a bit odd. :/
On Sep 6, 2007, at 10:04 AM, Josh Hursey wrote:
Weird this looks like a mirror issue again. Below is some more debug
output from MTT on BigRed:
<>
*** Reporter initializing
Evaluating: MTTDatabase
Initializing reporter module: MTTDatabase
Evaluating: require MTT::Reporter::MTTDatabase
Evaluating: $ret = &MTT::Reporter::MTTDatabase::Init(@args)
Evaluating: XXUsernameXX
Evaluating: XXPasswordXX
Evaluating: http://s10c2b3.dim:8008/
Evaluating: OMPI
Evaluating: 1
Evaluating: IU_BigRed
Set HTTP credentials for realm "OMPI"
MTTDatabase getting a client serial number...
MTTDatabase trying proxy: / Default (none)
MTTDatabase got response: Sorry, this page is not mirrored. Please
see the
http://www.open-mpi.org/mtt/submit/index.php";>original
version
of this page on the main Open MPI web site.
*** WARNING: MTTDatabase did not get a serial
Making dir:
/N/ptl01/mpiteam/bigred/20070906-CronTest-cron/pb_0/mttdatabase-
submit
(cwd: /N/ptl01/mpiteam/bigred/20070906-CronTest-cron/pb_0)
<>
In the INI file we have the following for the reporter so we can do
the redirect through the head node (s10c2b3.dim):
<>
[Reporter: IU database]
module = MTTDatabase
mttdatabase_realm = OMPI
mttdatabase_url = http://s10c2b3.dim:8008/
mttdatabase_username = XXUsernameXX
mttdatabase_password = XXPasswordXX
mttdatabase_platform = IU_BigRed
mttdatabase_keep_debug_files = 1
<>
It looks like IU is using the trunk version of the mtt-relay, and the
branch version of the MTT client. The mtt-relay code is the same on
both the trunk and the branch. The relay seems to be submitting to:
https://www.open-mpi.org/mtt/submit/index.php
Any thoughts on why this might be happening? It looks like the mirror
check is messed up again.
-- Josh
On Sep 5, 2007, at 11:31 PM, Josh Hursey wrote:
yeah I'll try to take a look at it tomorrow. I suspect that
something
is going wrong with the relay, but I can't really think of what it
might be at the moment.
-- Josh
On Sep 5, 2007, at 9:11 PM, Jeff Squyres wrote:
Josh / Ethan --
Not getting a serial means that the client is not getting a value
back from the server that it can parse into a serial.
Can you guys dig into this and see why the mtt dbdebug file that
Tim
has at the end of this message is not getting a serial?
Thanks...
On Sep 5, 2007, at 9:24 AM, Tim Prins wrote:
Here is the smallest one. Let me know if you need anything else.
Tim
Jeff Squyres wrote:
Can you send any one of those
Re: [MTT devel] [MTT users] Test runs not getting into database
(Off Users list for the moment)
A bit of debug output:
$_SERVER["SERVER_NAME"] = s10c2b3.dim
$mother_site = www.open-mpi.org
So it looks like the relay is doing something a bit odd. :/
On Sep 6, 2007, at 10:04 AM, Josh Hursey wrote:
Weird this looks like a mirror issue again. Below is some more debug
output from MTT on BigRed:
<>
*** Reporter initializing
Evaluating: MTTDatabase
Initializing reporter module: MTTDatabase
Evaluating: require MTT::Reporter::MTTDatabase
Evaluating: $ret = &MTT::Reporter::MTTDatabase::Init(@args)
Evaluating: XXUsernameXX
Evaluating: XXPasswordXX
Evaluating: http://s10c2b3.dim:8008/
Evaluating: OMPI
Evaluating: 1
Evaluating: IU_BigRed
Set HTTP credentials for realm "OMPI"
MTTDatabase getting a client serial number...
MTTDatabase trying proxy: / Default (none)
MTTDatabase got response: Sorry, this page is not mirrored. Please
see the
http://www.open-mpi.org/mtt/submit/index.php";>original
version
of this page on the main Open MPI web site.
*** WARNING: MTTDatabase did not get a serial
Making dir:
/N/ptl01/mpiteam/bigred/20070906-CronTest-cron/pb_0/mttdatabase-
submit
(cwd: /N/ptl01/mpiteam/bigred/20070906-CronTest-cron/pb_0)
<>
In the INI file we have the following for the reporter so we can do
the redirect through the head node (s10c2b3.dim):
<>
[Reporter: IU database]
module = MTTDatabase
mttdatabase_realm = OMPI
mttdatabase_url = http://s10c2b3.dim:8008/
mttdatabase_username = XXUsernameXX
mttdatabase_password = XXPasswordXX
mttdatabase_platform = IU_BigRed
mttdatabase_keep_debug_files = 1
<>
It looks like IU is using the trunk version of the mtt-relay, and the
branch version of the MTT client. The mtt-relay code is the same on
both the trunk and the branch. The relay seems to be submitting to:
https://www.open-mpi.org/mtt/submit/index.php
Any thoughts on why this might be happening? It looks like the mirror
check is messed up again.
-- Josh
On Sep 5, 2007, at 11:31 PM, Josh Hursey wrote:
yeah I'll try to take a look at it tomorrow. I suspect that something
is going wrong with the relay, but I can't really think of what it
might be at the moment.
-- Josh
On Sep 5, 2007, at 9:11 PM, Jeff Squyres wrote:
Josh / Ethan --
Not getting a serial means that the client is not getting a value
back from the server that it can parse into a serial.
Can you guys dig into this and see why the mtt dbdebug file that Tim
has at the end of this message is not getting a serial?
Thanks...
On Sep 5, 2007, at 9:24 AM, Tim Prins wrote:
Here is the smallest one. Let me know if you need anything else.
Tim
Jeff Squyres wrote:
Can you send any one of those mtt database files? We'll need to
figure out if this is a client or a server problem. :-(
On Sep 5, 2007, at 7:40 AM, Tim Prins wrote:
Hi,
BigRed has not gotten its test results into the database for a
while.
This is running the ompi-core-testers branch. We run by passing
the
results through the mtt-relay.
The mtt-output file has lines like:
*** WARNING: MTTDatabase did not get a serial; phases will be
isolated
from each other in the reports
Reported to MTTDatabase: 1 successful submit, 0 failed submits
(total of 1 result)
I have the database submit files if they would help.
Thanks,
Tim
___
mtt-users mailing list
mtt-us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
$VAR1 = {
'exit_signal_1' => -1,
'duration_1' => '5 seconds',
'mpi_version' => '1.3a1r16038',
'trial' => 0,
'mpi_install_section_name_1' => 'bigred 32 bit gcc',
'client_serial' => undef,
'hostname' => 's1c2b12',
'result_stdout_1' => '/bin/rm -f *.o *~ PI* core IMB-IO
IMB-EXT IMB-MPI1 exe_io exe_ext exe_mpi1
touch IMB_declare.h
touch exe_mpi1 *.c; rm -rf exe_io exe_ext
make MPI1 CPP=MPI1
make[1]: Entering directory `/N/ptl01/mpiteam/bigred/20070905-
Wednesday/pb_0/installs/d7Ri/tests/imb/IMB_2.3/src\'
mpicc -I. -DMPI1 -O -c IMB.c
mpicc -I. -DMPI1 -O -c IMB_declare.c
mpicc -I. -DMPI1 -O -c IMB_init.c
mpicc -I. -DMPI1 -O -c IMB_mem_manager.c
mpicc -I. -DMPI1 -O -c IMB_parse_name_mpi1.c
mpicc -I. -DMPI1 -O -c IMB_benchlist.c
mpicc -I. -DMPI1 -O -c IMB_strgs.c
mpicc -I. -DMPI1 -O -c IMB_err_handler.c
mpicc -I. -DMPI1 -O -c IMB_g_info.c
mpicc -I. -DMPI1 -O -c IMB_warm_up.c
mpicc -I. -DMPI1 -O -c IMB_output.c
mpicc -I. -DMPI1 -O -c IMB_pingpong.c
mpicc -I. -DMPI1 -O -c IMB_pingping.c
mpicc -I. -DMPI1 -O -c IMB_allreduce.c
mpicc -I. -DMPI1 -O -c IMB_reduce_scatter.c
mpicc -I. -DMPI
Re: [MTT devel] [MTT users] Test runs not getting into database
Weird this looks like a mirror issue again. Below is some more debug
output from MTT on BigRed:
<>
*** Reporter initializing
Evaluating: MTTDatabase
>> Initializing reporter module: MTTDatabase
Evaluating: require MTT::Reporter::MTTDatabase
Evaluating: $ret = &MTT::Reporter::MTTDatabase::Init(@args)
Evaluating: XXUsernameXX
Evaluating: XXPasswordXX
Evaluating: http://s10c2b3.dim:8008/
Evaluating: OMPI
Evaluating: 1
Evaluating: IU_BigRed
Set HTTP credentials for realm "OMPI"
MTTDatabase getting a client serial number...
MTTDatabase trying proxy: / Default (none)
MTTDatabase got response: Sorry, this page is not mirrored. Please
see the
http://www.open-mpi.org/mtt/submit/index.php";>original
version
of this page on the main Open MPI web site.
*** WARNING: MTTDatabase did not get a serial
Making dir:
/N/ptl01/mpiteam/bigred/20070906-CronTest-cron/pb_0/mttdatabase-
submit
(cwd: /N/ptl01/mpiteam/bigred/20070906-CronTest-cron/pb_0)
<>
In the INI file we have the following for the reporter so we can do
the redirect through the head node (s10c2b3.dim):
<>
[Reporter: IU database]
module = MTTDatabase
mttdatabase_realm = OMPI
mttdatabase_url = http://s10c2b3.dim:8008/
mttdatabase_username = XXUsernameXX
mttdatabase_password = XXPasswordXX
mttdatabase_platform = IU_BigRed
mttdatabase_keep_debug_files = 1
<>
It looks like IU is using the trunk version of the mtt-relay, and the
branch version of the MTT client. The mtt-relay code is the same on
both the trunk and the branch. The relay seems to be submitting to:
https://www.open-mpi.org/mtt/submit/index.php
Any thoughts on why this might be happening? It looks like the mirror
check is messed up again.
-- Josh
On Sep 5, 2007, at 11:31 PM, Josh Hursey wrote:
yeah I'll try to take a look at it tomorrow. I suspect that something
is going wrong with the relay, but I can't really think of what it
might be at the moment.
-- Josh
On Sep 5, 2007, at 9:11 PM, Jeff Squyres wrote:
Josh / Ethan --
Not getting a serial means that the client is not getting a value
back from the server that it can parse into a serial.
Can you guys dig into this and see why the mtt dbdebug file that Tim
has at the end of this message is not getting a serial?
Thanks...
On Sep 5, 2007, at 9:24 AM, Tim Prins wrote:
Here is the smallest one. Let me know if you need anything else.
Tim
Jeff Squyres wrote:
Can you send any one of those mtt database files? We'll need to
figure out if this is a client or a server problem. :-(
On Sep 5, 2007, at 7:40 AM, Tim Prins wrote:
Hi,
BigRed has not gotten its test results into the database for a
while.
This is running the ompi-core-testers branch. We run by passing
the
results through the mtt-relay.
The mtt-output file has lines like:
*** WARNING: MTTDatabase did not get a serial; phases will be
isolated
from each other in the reports
Reported to MTTDatabase: 1 successful submit, 0 failed submits
(total of 1 result)
I have the database submit files if they would help.
Thanks,
Tim
___
mtt-users mailing list
mtt-us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
$VAR1 = {
'exit_signal_1' => -1,
'duration_1' => '5 seconds',
'mpi_version' => '1.3a1r16038',
'trial' => 0,
'mpi_install_section_name_1' => 'bigred 32 bit gcc',
'client_serial' => undef,
'hostname' => 's1c2b12',
'result_stdout_1' => '/bin/rm -f *.o *~ PI* core IMB-IO
IMB-EXT IMB-MPI1 exe_io exe_ext exe_mpi1
touch IMB_declare.h
touch exe_mpi1 *.c; rm -rf exe_io exe_ext
make MPI1 CPP=MPI1
make[1]: Entering directory `/N/ptl01/mpiteam/bigred/20070905-
Wednesday/pb_0/installs/d7Ri/tests/imb/IMB_2.3/src\'
mpicc -I. -DMPI1 -O -c IMB.c
mpicc -I. -DMPI1 -O -c IMB_declare.c
mpicc -I. -DMPI1 -O -c IMB_init.c
mpicc -I. -DMPI1 -O -c IMB_mem_manager.c
mpicc -I. -DMPI1 -O -c IMB_parse_name_mpi1.c
mpicc -I. -DMPI1 -O -c IMB_benchlist.c
mpicc -I. -DMPI1 -O -c IMB_strgs.c
mpicc -I. -DMPI1 -O -c IMB_err_handler.c
mpicc -I. -DMPI1 -O -c IMB_g_info.c
mpicc -I. -DMPI1 -O -c IMB_warm_up.c
mpicc -I. -DMPI1 -O -c IMB_output.c
mpicc -I. -DMPI1 -O -c IMB_pingpong.c
mpicc -I. -DMPI1 -O -c IMB_pingping.c
mpicc -I. -DMPI1 -O -c IMB_allreduce.c
mpicc -I. -DMPI1 -O -c IMB_reduce_scatter.c
mpicc -I. -DMPI1 -O -c IMB_reduce.c
mpicc -I. -DMPI1 -O -c IMB_exchange.c
mpicc -I. -DMPI1 -O -c IMB_bcast.c
mpicc -I. -DMPI1 -O -c IMB_barrier.c
mpicc -I. -DMPI1 -O -c IMB_allgather.c
mpicc -I. -DMPI1 -O -c IMB_allgatherv.c
mpicc
[MTT devel] First cut at MTT web pages
I put up a skeleton of the MTT web pages on the OMPI web site, but didn't link to them from anywhere. This actually involved changing a bunch of infrastructure because we published the name /projects/mtt/ in the paper but PLPA was under /software/plpa/. So I had to move PLPA to be under /projects/plpa/etc. You probably don't care about the details. ;-) Anyway, /projects/mtt/ now exists and has skeleton content. I even put up dummy tarballs (that are empty). Two things to note: 1. There are 3 places where I have links to MTT content on the OMPI web site. If you are in a personal checkout (i.e., if the first two chars of REQUEST_URI are "/~"), the links will show up and be noted with "(FIX)" in red. If you're on the live OMPI web site, the links don't show up (yet). 2. Our OMPI MTT testing results are in /mtt/ -- the MTT project site is /projects/mtt/. This actually creates a problem for the left-hand navigation scheme because it looks at the basename of the subdir to know when to print the sub-menus. For example, if you view a personal checkout and go to /projects/mtt/, you'll see the MTT project sub-menu listed twice on the left. I could add a hackaround in the PHP of the OMPI web site, but thinking about it a little, I wonder if it would be better to simply move the OMPI MTT testing results to /testing/ (with an appropriate apache-level redirects left at /mtt/ so that all old permalinks and whatnot continue to work). We'll need to get everyone to update their client INI files, though -- I'm not sure that LWP will understand a POST redirect...? Comments? -- Jeff Squyres Cisco Systems
