[MTT users] multiple testing configurations from a single workspace

[Ethan Mallove]

Hi Folks,

Is there a way to test multiple test configurations from a single 
workspace simultaneously in MTT? For example, I want to run a set of 
tests on i386 and sparc at the same time from a single testing 
workspace. Looking at the sample.ini file, it seems like this could be 
done using multiple .ini files and setting each "copydir" in each to run 
in a different workspace to avoid conflicts amongst multiple instances 
of MTT.


It turns out that this is a limitation of TET (I think). Right now, in 
order to do the above I have to create a separate testing area for each 
testing configuration (e.g., sparc, i386, solaris 10, solaris 11, ...) 
to avoid multiple TET's from interfering with each other.


-Ethan

[MTT users] Run MTT with pre-built ompi

[Ethan Mallove]

MTT-ers,

I want to skip the MPI Get and Install phases, and simply point MTT to 
my pre-built/installed Open MPI. Can this be done in the .ini file, or 
do I need to create a whole module to do this? I thought that just 
inserting "installdir = /my/ompi/installation" in the [MPI Install: foo] 
section would do that. I also created a Null.pm module that does nothing 
(contents: "1;") so MTT would bark at me for not supplying a module 
parameter.


I must be missing something.

-Ethan

[MTT users] mtt-users mail archive

[Ethan Mallove]

I get a "Not Found" error when I try to access the mtt-users mail 
archives here:


http://www.open-mpi.org/MailArchives/mtt-users/

If there's no quick fix for this, I'd be psyched if someone could just 
forward me any [MTT-users] mail they have in their box that's older than 
4/10/06.


-Ethan

[MTT users] escaping quotes issue in DoCommand.pm

[Ethan Mallove]

I think there's an issue with escaping quotes either in DoCommand.pm, 
though there's an easy workaround.


The problem is the following .ini param will not work for me without a 
minor change to OMPI:


configure_arguments = CFLAGS="-xarch=v8plusa -xO5"

Here's a simple test program that illustrates the issue:

---

$ perl -I/trunk/lib -d ./test_DoCommand
$ cat test_DoCommand
#!/usr/bin/perl

use MTT::DoCommand;

# works!
MTT::DoCommand::Cmd(0, qw{./configure CFLAGS="-g -xarch=v8plusa" 
--enable-picky --enable-debug --disable-mpi-f90});


# doesn't work
MTT::DoCommand::Cmd(0, "./configure CFLAGS="-g -xarch=v8plusa" 
--enable-picky --enable-debug --disable-mpi-f90"});


---

Here's the workaround that seems to do the trick:

em162155@burl-ct-v440-6-a /workspace/em162155/hpc/mtt/trunk 234> svn 
diff lib/MTT/MPI/Install/OMPI.pm

Index: lib/MTT/MPI/Install/OMPI.pm
===
--- lib/MTT/MPI/Install/OMPI.pm (revision 185)
+++ lib/MTT/MPI/Install/OMPI.pm (working copy)
@@ -59,7 +59,7 @@
$ret->{bindir} = "$ret->{installdir}/bin";
$ret->{libdir} = "$ret->{installdir}/lib";

-$x = MTT::DoCommand::Cmd(1, "$config->{configdir}/configure 
$config->{configure_arguments} --prefix=$ret->{installdir}");
+$x = MTT::DoCommand::Cmd(1, ("$config->{configdir}/configure", 
$config->{configure_arguments}, "--prefix=$ret->{installdir}"));
$stdout = $x->{stdout} ? "--- Configure stdout/stderr 
---\n$x->{stdout}" :

undef;
if ($x->{status} != 0) {

---

I think I would favor a revision to lines 101-133 in DoCommand because 
it seems more natural to write DoCommand("foo bar baz"), then 
DoCommand(foo, bar, baz). But I need to think more about how to do it.


-Ethan

[MTT users] sha1sum on x64 Solaris

[Ethan Mallove]

I'm not sure sha1sum is installed by default on x64 Solaris systems. I don't 
see it on any of our
x64 Solaris lab machines. (Not sure how this wasn't a problem until now.) Until 
we figure out how to
do SHA1 checksums on x64 Solaris, my workaround is to simply change Abort to 
Debug when the sha1sum
checksum comparison fails:


Index: lib/MTT/MPI/Get/OMPI_Snapshot.pm
===
--- lib/MTT/MPI/Get/OMPI_Snapshot.pm(revision 191)
+++ lib/MTT/MPI/Get/OMPI_Snapshot.pm(working copy)
@@ -128,7 +128,7 @@
 my $sha1_file = `grep $ret->{version}.tar.gz $sha1_checksums | cut -d\\  
-f1`;
 chomp($sha1_file);
 my $sha1_actual = MTT::Files::sha1sum("$tarball_dir/$tarball_name");
-Abort("sha1sum from checksum file does not match actual ($sha1_file != 
$sha1_actual)")
+Debug("sha1sum from checksum file does not match actual ($sha1_file != 
$sha1_actual)")
 if ($sha1_file ne $sha1_actual);
 Debug(">> Good sha1sum\n");


-Ethan

Re: [MTT users] [Fwd: [perfbase-users] Submitting a run in multiple steps]

[Ethan Mallove]

Jeff Squyres (jsquyres) wrote On 07/10/06 17:48,:
>>-Original Message-
>>From: Joachim Worringen [mailto:joac...@dolphinics.com] 
>>Sent: Monday, July 10, 2006 7:41 AM
>>To: us...@perfbase.tigris.org
>>Subject: Re: [Fwd: [perfbase-users] Submitting a run in 
>>multiple steps]
>>
>>The current version of perfbase does no longer create a new table for 
>>each run, but only a new index. Indexes are cheap, but queries might 
>>become somewhat slower if a large list of run indexes has to be 
>>processed. Note that this really reads *might*, as I don't 
>>know how well 
>>PostgreSQL handles/optimizes such SQL constructs.
> 
> 
> Good to know.
>  
> 
>>It's an important characteristic of perfbase that runs can not be 
>>modified once they have been created. Thus, the thing you thought of 
>>won't be possible.
>>
>>However, it is possible to create a single run from an 
>>unlimited number 
>>of input files by using the "--join" option for the input command. I 
>>guess that's the way to go. Additionally, if you can not 
>>avoid to create 
>>multiple perfbase runs for a single test suite run, you should group 
>>these run via a dedicated parameter value, or use the 
>>synopsis for this.
> 
> 
> I think the latter is what we'll likely do; our goal is to see partial
> results (e.g., not have to wait 10 hours to see that every single test
> failed) rather than be able to submit lots of results at once.
> 

To see partial results, I have this in my .ini file:

---

[Reporter: IU database]
module = Perfbase

perfbase_realm = OMPI
perfbase_username = postgres
... [snip] ...
perfbase_debug_filename = pb_debug

---

I can then look at the pb_debug* files to see the results as they're happening. 
They're not pretty
results in tabular or graphical format, but could these raw results suffice for 
most situations?
E.g., you can get a pretty good idea of how the tests are going by just doing:

$ grep -E 'test_pass|test_name' pb_debug*
pb_debug.0.txt:test_name: c_hello
pb_debug.0.txt:test_pass: 1
pb_debug.1.txt:test_name: cxx_hello
pb_debug.1.txt:test_pass: 1
pb_debug.10.txt:test_name: MPI_Barrier_c
pb_debug.10.txt:test_pass: 1
pb_debug.11.txt:test_name: MPI_Bcast_c
pb_debug.11.txt:test_pass: 1
... [snip] ...


I think though, that the Perbase.pm code needs to be adjusted to allow for 
results to go to both the
perfbase debug files _and_ to IU's perfbase simultaneously (right now there's 
an if-else preventing
this).

-Ethan


> Thanks!
> 

Re: [MTT users] [MTT svn] svn:mtt r196 - in trunk: lib/MTT lib/MTT/Reporter server

[Ethan Mallove]

Here's the log which was not added to the repository because I accidentally
typed "c" at the "a)bort, c)ontinue, e)dit" svn commit prompt.

- Show user where the perfbase HTTP POST is going in host:port/dir
  format.
- env_proxy => 1 is unreliable. Look for the proxy in the user's env and
  explicitly set it for the UserAgent
- Allow for sending data to perfbase _and_ output to perfbase debug
  files (before it had to be one or the other). Note: to turn off
  uploading test results to perfbase, set perfbase_url to an invalid
  url
- Adjusted some MTT defaults
- Some typos fixed

-Ethan


em162...@osl.iu.edu wrote On 07/14/06 11:47,:
> Author: em162155
> Date: 2006-07-14 11:46:44 -0400 (Fri, 14 Jul 2006)
> New Revision: 196
> 
> Modified:
>trunk/lib/MTT/Defaults.pm
>trunk/lib/MTT/Reporter/Perfbase.pm
>trunk/server/mtt_config.php.perfbase.sample
>trunk/server/perfbase.php
> Log:
> 
> 
> Modified: trunk/lib/MTT/Defaults.pm
> ===
> --- trunk/lib/MTT/Defaults.pm 2006-07-11 16:42:27 UTC (rev 195)
> +++ trunk/lib/MTT/Defaults.pm 2006-07-14 15:46:44 UTC (rev 196)
> @@ -25,7 +25,7 @@
>  
>  http_agents => "wget lynx curl",
>  
> -known_compiler_names => "gnu pgi intel kai absoft pathscale none",
> +known_compiler_names => "gnu pgi intel kai absoft pathscale sun none",
>  };
>  
>  # User-defined configuration
> @@ -60,7 +60,7 @@
>  
>  # Test run phase
>  our $Test_run = {
> -perfbase_xml => "inp_test_run.xml",
> +perfbase_xml => "inp_test_run_correctness.xml",
>  argv => "",
>  np => 2,
>  np_ok => 1,
> 
> Modified: trunk/lib/MTT/Reporter/Perfbase.pm
> ===
> --- trunk/lib/MTT/Reporter/Perfbase.pm2006-07-11 16:42:27 UTC (rev 
> 195)
> +++ trunk/lib/MTT/Reporter/Perfbase.pm2006-07-14 15:46:44 UTC (rev 
> 196)
> @@ -3,6 +3,7 @@
>  # Copyright (c) 2005-2006 The Trustees of Indiana University.
>  # All rights reserved.
>  # Copyright (c) 2006  Cisco Systems, Inc.  All rights reserved.
> +# Copyright (c) 2006  Sun Microsystems, Inc.  All rights reserved.
>  # $COPYRIGHT$
>  # 
>  # Additional copyrights may follow
> @@ -25,6 +26,7 @@
>  my $password;
>  my $realm;
>  my $url;
> +my $port;
>  
>  # platform common name
>  my $platform;
> @@ -58,7 +60,7 @@
>  ++$count if ($password);
>  ++$count if ($realm);
>  if ($count > 0 && $count != 3) {
> -Warning("Perfbase Reporter section [$section]: if password, 
> username, or relam is specified, they all must be specified.\n");
> +Warning("Perfbase Reporter section [$section]: if password, 
> username, or realm is specified, they all must be specified.\n");
>  return undef;
>  }
>  $platform = Value($ini, $section, "perfbase_platform");
> @@ -66,24 +68,40 @@
>  # Extract the host and port from the URL.  Needed for the
>  # credentials section.
>  
> -my $port;
> +my $dir;
>  my $host = $url;
> -if ($host =~ /http:\/\/([-a-zA-Z0-9.]+):(\d+)/) {
> +if ($host =~ /(http:\/\/[-a-zA-Z0-9.]+):(\d+)\/(.*)$/) {
>  $host = $1;
>  $port = $2;
> -} elsif ($host =~ /http:\/\/([-a-zA-Z0-9.]+)/) {
> +$dir = $3;
> +} elsif ($host =~ /(http:\/\/[-a-zA-Z0-9.]+)\/(.*)$/) {
>  $host = $1;
> +$dir = $2;
>  $port = 80;
> -} elsif ($host =~ /https:\/\/([-a-zA-Z0-9.]+)/) {
> +} elsif ($host =~ /(https:\/\/[-a-zA-Z0-9.]+)\/(.*)$/) {
>  $host = $1;
> +$dir = $2;
>  $port = 443;
>  } else {
>  return undef;
>  }
> +$url = "$host:$port/$dir";
>  
> +# Look for the proxy server in the environment,
> +# and take the first one we find
> +my $proxy;
> +foreach my $p (grep(/http_proxy/i, keys %ENV)) {
> +if ($ENV{$p}) {
> +$proxy = $ENV{$p};
> +$proxy = "http://$proxy"; if ($proxy !~ /https?:/);
> +last;
> +}
> +}
> +
>  # Create the Perl LWP stuff to setup for HTTP PUT's later
>  
> -$ua = LWP::UserAgent->new({ env_proxy => 1 });
> +$ua = LWP::UserAgent->new();
> +$ua->proxy(['http', 'ftp'], $proxy);
>  $ua->agent("MPI Test Perfbase Reporter");
>  if ($realm && $username && $password) {
>  Verbose("   Set HTTP credentials for realm \"$realm\"\n");
> @@ -186,10 +204,10 @@
>  PBXML => $xml,
>  };
>  
> -if (0 && !$debug_filename) {
> +if ($url) {
>  # Do the post and get the response.
>  
> -Debug("Submitting to perbase...\n");
> +Debug("Submitting to perfbase...\n");
>  my $response = $ua->post($url, $form);
>  if ($response->is_success()) {
> 

[MTT users] adding LWP::UserAgent to MTT repository

[Ethan Mallove]

I thought it would be nice to not require users to have LWP::UserAgent installed
 (like we don't require them to have Config::IniFiles - it's part of the MTT
repository), since LWP::UserAgent isn't listed as a standard module
(https://www.linuxnotes.net/perlcd/prog/ch32_01.htm). However, LWP::UserAgent
uses a platform dependent binary called Parser.so which makes the addition of
LWP::UserAgent to the repos slightly more involved. E.g., putting Parser.so in
sparc, i386, etc. directories and getting UserAgent to look for them in the
right place. For now, LWP::UserAgent can be put in a centralized location that
the PERLLIB env var can point to.

-Ethan

Re: [MTT users] adding LWP::UserAgent to MTT repository

[Ethan Mallove]

Jeff Squyres (jsquyres) wrote On 07/17/06 10:13,:
> It might be ok to adapt the module to try to "include" it (vs. requiring
> it) and if it's not there, fail over.
> 
> Make sense? 


Do you mean adapt Perfbase.pm fail over if it can't find LWP::UserAgent?  Or
adapt LWP::UserAgent to failover if it can't find HTML::HeadParser (which I
think needs Parser.so). Or both?


> 
> 
>>-Original Message-
>>From: mtt-users-boun...@open-mpi.org 
>>[mailto:mtt-users-boun...@open-mpi.org] On Behalf Of Ethan Mallove
>>Sent: Monday, July 17, 2006 9:46 AM
>>To: mtt-us...@open-mpi.org
>>Subject: [MTT users] adding LWP::UserAgent to MTT repository
>>
>>I thought it would be nice to not require users to have 
>>LWP::UserAgent installed
>> (like we don't require them to have Config::IniFiles - it's 
>>part of the MTT
>>repository), since LWP::UserAgent isn't listed as a standard module
>>(https://www.linuxnotes.net/perlcd/prog/ch32_01.htm). 
>>However, LWP::UserAgent
>>uses a platform dependent binary called Parser.so which makes 
>>the addition of
>>LWP::UserAgent to the repos slightly more involved. E.g., 
>>putting Parser.so in
>>sparc, i386, etc. directories and getting UserAgent to look 
>>for them in the
>>right place. For now, LWP::UserAgent can be put in a 
>>centralized location that
>>the PERLLIB env var can point to.
>>
>>-Ethan
>>
>>___
>>mtt-users mailing list
>>mtt-us...@open-mpi.org
>>http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
>>
> 
> 
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

[MTT users] perfbase.php not slurping test run data

[Ethan Mallove]

perfbase.php seems to only populate perfbase with mpi_install and test_build
data. In other words, data correlating to these files is getting input to
perfbase:

  inp_mpi_install.xml
  inp_test_build.xml

Data correlating to this file is _not_ getting input to perfbase:

  inp_test_run_correctness.xml

I verified this by looking at the perfbase data with pg_dump (postgres's
command-line tool to dump the entire database), which shows that there is no
data for these fields:

test_pass
test_command
test_name
test_np
test_message
stderr
"stdout"
start_timestamp
stop_timestamp

The above fields belong to the rundata table. I can see from the perfbase
--debug output there are UPDATEs/INSERTs into the below tables, but no
UPDATEs/INSERTs into rundata:

run_metadata
rundata_once

It looks like the data is getting parsed correctly:

E.g.,

#* checking : found 'test_name: '
#* parsing  'test_name: '
   content for 'test_name': 'f77_hello'
*# Processing line:
test_np: 2
#* checking : found 'test_np: '
#* parsing  'test_np: '
   content for 'test_np': '2'

   ... [snip] ...

And there are no error messages from perfbase. Can anyone give me a tip on how
to track down the missing data?

-Ethan

Re: [MTT users] perfbase.php not slurping test run data

[Ethan Mallove]

Jeff Squyres (jsquyres) wrote On 07/18/06 19:43,:
> I would try this manually, without the php script in between.
> Specifically:
> 
> 1. I would modify the .php script to write out a file
> 2. send a submit through the .php file
> 3. examine the resulting file and ensure that all the fields match up to
> what you think they should be
> 4. manually submit this file to perfbase and see what happens
> 

I can't get it to work outside of the php script either:

$ date
Wed Jul 19 12:34:49 EDT 2006
$ cat pb.in | perfbase input -v -i -d www/inp_test_run_correctness.xml -
#* importing data from
- (parsed according to www/inp_test_run_correctness.xml)
#* Parsing input description from XML file www/inp_test_run_correctness.xml
#* Processing data file  -
#+ Creating new run with index 5
$ cat pb.in
hostname: burl-ct-v20z-0
os_name: SunOS
os_version: SunOS 5.10
platform_hardware: i86pc
platform_type: solaris-10
submit_timestamp: Mon Jul 17 18:30:48 2006
mpi_install_section_name: solaris i386
mpi_name: ompi-nightly-v1.0
mpi_version: 1.0.3a1r10793
mtt_version_major: 0
mtt_version_minor: 5
perfbase_xml: inp_test_run_correctness.xml
phase: Test run
platform_id: IU Odin cluster
start_timestamp: Mon Jul 17 18:30:45 2006
stop_timestamp: Mon Jul 17 18:30:48 2006
test_build_section_name: trivial
test_command: mpirun -np 2 --prefix
/workspace/em162155/hpc/mtt/trunk/installs/ompi-nightly-v1.0/solaris_i386/install
./f77_hello
test_message: Passed
test_name: f77_hello
test_np: 2
test_pass: 1
test_run_section_name: trivial
merge_stdout_stderr: 0
mpi_get_section_name: solaris i386
ENVIRONMENT_BEGIN
foo = bar
ENVIRONMENT_END
STDERR_BEGIN
blah blah blah
STDERR_END
STDOUT_BEGIN
blah blah blah
STDOUT_END
$ perfbase ls -l --exp=test_run_correctness -v
--show=mtt_version_major,mtt_version_minor,hostname,os_name,os_version,platform_hardware,platform_type,platform_id,environment,mpi_name,mpi_version,mpi_get_section_name,mpi_install_section_name,test_build_section_name,test_run_section_name,merge_stdout_stderr,test_command,test_message,test_name,test_np,test_pass,stderr,stdout,submit_timestamp,start_timestamp,stop_timestamp
--nvals=999 | tail -2
5   postgres2006-07-19 12:34:49.00  0   5   burl-ct-v20z-0
SunOS   SunOS 5.10  i86pc   solaris-10  IU Odin cluster foo = bar
ompi-nightly-v1.0   1.0.3a1r10793   solaris i386solaris i386
trivial trivial 0   #no_data#   #no_data#   #no_data#   #no_data#
#no_data#   #no_data#   #no_data#   2006-07-17 18:30:48.00
#no_data#   #no_data#

---

The timestamp for the perfbase input and ls matches, which shows *something* was
inserted into perfbase, but shouldn't I see "Passed", "f77_hello", "2", etc.
where the perfbase ls output shows #no_data#? (Note: I took the -u option out of
perfbase input to be more "strict" for the time being.)

I'm not able to insert data into one of the problematic fields with perfbase's
fixed content option (-f name=val). E.g.,

$ cat pb.in | perfbase input -f test_name=f77_hello -v -i -d
www/inp_test_run_correctness.xml -

Tried to delete the experiment and do a re-setup, but that didn't help.

$ perfbase delete --exp=test_run_correctness
$ perfbase setup --desc=www/exp_test_run_correctness.xml

The pattern I see is that the problematic fields are set to
occurrence="multiple". For these fields I've set retrigger=yes (which should be
the default) to force an update to occur if the row exists - no luck.

I'm not sure if this is a problem in the exp_*.xml files or the inp_*.xml 
files?.

Also, how was it determined in the exp*.xml file, which fields were to be a
"parameter" and which were to be a "result"? Looks like the only difference is a
parameter can nest 0 or more "valid" elements.

-Ethan


> That's what I would do.
>  
> 
> 
>>-Original Message-
>>From: mtt-users-boun...@open-mpi.org 
>>[mailto:mtt-users-boun...@open-mpi.org] On Behalf Of Ethan Mallove
>>Sent: Tuesday, July 18, 2006 6:33 PM
>>To: mtt-us...@open-mpi.org
>>Subject: [MTT users] perfbase.php not slurping test run data
>>
>>perfbase.php seems to only populate perfbase with mpi_install 
>>and test_build
>>data. In other words, data correlating to these files is 
>>getting input to
>>perfbase:
>>
>>  inp_mpi_install.xml
>>  inp_test_build.xml
>>
>>Data correlating to this file is _not_ getting input to perfbase:
>>
>>  inp_test_run_correctness.xml
>>
>>I verified this by looking at the perfbase data with pg_dump 
>>(postgres's
>>command-line tool to dump the entire database), which shows 
>>that there is no
>>data for these fields:
>>
>>test_pass
>>test_command
>>test_name
>>

Re: [MTT users] perfbase.php not slurping test run data

[Ethan Mallove]

FYI ...

We've narrowed this issue down to all results with occurrence="once" will input,
but if occurrence="multiple" - we see #no_data#.

I posted a question to users@perfbase if you're interested in following it 
there:

http://perfbase.tigris.org/servlets/ReadMsg?list=users&msgNo=126

-Ethan


Ethan Mallove wrote On 07/19/06 13:25,:
> Jeff Squyres (jsquyres) wrote On 07/18/06 19:43,:
> 
>>I would try this manually, without the php script in between.
>>Specifically:
>>
>>1. I would modify the .php script to write out a file
>>2. send a submit through the .php file
>>3. examine the resulting file and ensure that all the fields match up to
>>what you think they should be
>>4. manually submit this file to perfbase and see what happens
>>
> 
> 
> I can't get it to work outside of the php script either:
> 
> $ date
> Wed Jul 19 12:34:49 EDT 2006
> $ cat pb.in | perfbase input -v -i -d www/inp_test_run_correctness.xml -
> #* importing data from
> - (parsed according to www/inp_test_run_correctness.xml)
> #* Parsing input description from XML file www/inp_test_run_correctness.xml
> #* Processing data file  -
> #+ Creating new run with index 5
> $ cat pb.in
> hostname: burl-ct-v20z-0
> os_name: SunOS
> os_version: SunOS 5.10
> platform_hardware: i86pc
> platform_type: solaris-10
> submit_timestamp: Mon Jul 17 18:30:48 2006
> mpi_install_section_name: solaris i386
> mpi_name: ompi-nightly-v1.0
> mpi_version: 1.0.3a1r10793
> mtt_version_major: 0
> mtt_version_minor: 5
> perfbase_xml: inp_test_run_correctness.xml
> phase: Test run
> platform_id: IU Odin cluster
> start_timestamp: Mon Jul 17 18:30:45 2006
> stop_timestamp: Mon Jul 17 18:30:48 2006
> test_build_section_name: trivial
> test_command: mpirun -np 2 --prefix
> /workspace/em162155/hpc/mtt/trunk/installs/ompi-nightly-v1.0/solaris_i386/install
> ./f77_hello
> test_message: Passed
> test_name: f77_hello
> test_np: 2
> test_pass: 1
> test_run_section_name: trivial
> merge_stdout_stderr: 0
> mpi_get_section_name: solaris i386
> ENVIRONMENT_BEGIN
> foo = bar
> ENVIRONMENT_END
> STDERR_BEGIN
> blah blah blah
> STDERR_END
> STDOUT_BEGIN
> blah blah blah
> STDOUT_END
> $ perfbase ls -l --exp=test_run_correctness -v
> --show=mtt_version_major,mtt_version_minor,hostname,os_name,os_version,platform_hardware,platform_type,platform_id,environment,mpi_name,mpi_version,mpi_get_section_name,mpi_install_section_name,test_build_section_name,test_run_section_name,merge_stdout_stderr,test_command,test_message,test_name,test_np,test_pass,stderr,stdout,submit_timestamp,start_timestamp,stop_timestamp
> --nvals=999 | tail -2
> 5   postgres2006-07-19 12:34:49.00  0   5   burl-ct-v20z-0
> SunOS   SunOS 5.10  i86pc   solaris-10  IU Odin cluster foo = bar
> ompi-nightly-v1.0   1.0.3a1r10793   solaris i386solaris i386
> trivial trivial 0   #no_data#   #no_data#   #no_data#   #no_data#
> #no_data#   #no_data#   #no_data#   2006-07-17 18:30:48.00
> #no_data#   #no_data#
> 
> ---
> 
> The timestamp for the perfbase input and ls matches, which shows *something* 
> was
> inserted into perfbase, but shouldn't I see "Passed", "f77_hello", "2", etc.
> where the perfbase ls output shows #no_data#? (Note: I took the -u option out 
> of
> perfbase input to be more "strict" for the time being.)
> 
> I'm not able to insert data into one of the problematic fields with perfbase's
> fixed content option (-f name=val). E.g.,
> 
> $ cat pb.in | perfbase input -f test_name=f77_hello -v -i -d
> www/inp_test_run_correctness.xml -
> 
> Tried to delete the experiment and do a re-setup, but that didn't help.
> 
> $ perfbase delete --exp=test_run_correctness
> $ perfbase setup --desc=www/exp_test_run_correctness.xml
> 
> The pattern I see is that the problematic fields are set to
> occurrence="multiple". For these fields I've set retrigger=yes (which should 
> be
> the default) to force an update to occur if the row exists - no luck.
> 
> I'm not sure if this is a problem in the exp_*.xml files or the inp_*.xml 
> files?.
> 
> Also, how was it determined in the exp*.xml file, which fields were to be a
> "parameter" and which were to be a "result"? Looks like the only difference 
> is a
> parameter can nest 0 or more "valid" elements.
> 
> -Ethan
> 
> 
> 
>>That's what I would do.
>> 
>>
>>
>>
>>>-Original Message-
>>>From: mtt-users-boun...@open-mpi.org 
>>>[mailto:mt

[MTT users] nightly results format

[Ethan Mallove]

Here's a draft for a nightly test results email format. One
will receive reports through mtt-resu...@open-mpi.org.
Note: The following is a faux-report. Just pretend there is
nothing non-sensical about the data.

This might be better sent as an attachment, or a link to a
webpage as lots of email clients have default textwidth
settings that will make the formatted tables look like
gobbledygook.

We are also planning a webpage frontend (e.g.,
www.open-mpi.org/mtt-results.php) to the test results with
more flexibility in generating reports than this static
email report. In other words, we're leaving out lots of
bells and whistles here as those will be implemented in the
webpage frontend.

-Ethan


==

Subject: Test results for 
Body:

* Failed MPI Install(s)

os_version: SunOS 5.10
platform_hardware: i86pc
platform_id: Sun's Cluster
mpi_name: ompi-nightly-v1.0
mpi_version: 1.0.3a1r10793

http://www.open-mpi.org/mtt/mpi_install_logs/config.log.
http://www.open-mpi.org/mtt/mpi_install_logs/make.log.

* Failed Test Build(s)

os_version: SunOS 5.10
platform_hardware: i86pc
platform_id: Sun's Cluster
mpi_name: ompi-nightly-v1.0
mpi_version: 1.0.3a1r10793

+++-++
| #  |time|   cat   |  name  |
+++-++
| 1  | 2006-07-20 | ibm | test_abc   |
| 2  | 2006-07-20 | ibm | test_xyz   |
| 3  | 2006-07-20 | intel   | test_123   |

[snip] ...

[1]

environment: foo = bar
compiler_flags: -g -fugly-complex -fno-globals -Wno-globals -Isrc -I.
stderr: blah blah blah
stdout: blah blah blah

* Failed Test Run(s)

os_version: SunOS 5.10
platform_hardware: i86pc
platform_id: Sun's Cluster
mpi_name: ompi-nightly-v1.0
mpi_version: 1.0.3a1r10793

+++-++
| #  |time|   cat   |  name  |
+++-++
| 1  | 2006-07-20 | ibm | zero1  |
| 2  | 2006-07-20 | ibm | spawn  |
| 3  | 2006-07-20 | ibm | spawn_multiple |
| 4  | 2006-07-20 | ibm | abort  |
| 5  | 2006-07-20 | ibm | final  |
| 6  | 2006-07-20 | intel   | init_thread_funneled   |
| 7  | 2006-07-20 | intel   | init_thread_serialized |
| 8  | 2006-07-20 | intel   | init_thread_multiple   |
| 9  | 2006-07-20 | imb | range  |
| 10 | 2006-07-20 | imb | cart   |
| 11 | 2006-07-20 | imb | graph  |
| 12 | 2006-07-20 | imb | sub|

[snip] ...

* Failed Test Run Details

[1]

environment: foo = bar
test_command: mpirun -np 2 --prefix
/workspace/em162155/hpc/mtt/trunk/installs/ompi-nightly-v1.0/solaris_i386/install
./zero1
stderr: blah blah blah
stdout: blah blah blah

[2]

environment: foo = bar
test_command: mpirun -np 2 --prefix
/workspace/em162155/hpc/mtt/trunk/installs/ompi-nightly-v1.0/solaris_i386/install
./spawn
stderr: blah blah blah
stdout: blah blah blah

[snip] ...

* Failed Test(s)

os_version: Linux
platform_hardware: i86pc
platform_id: IU Odin Cluster
mpi_name: ompi-nightly-v1.0
mpi_version: 1.0.3a1r10793

+++-++
| #  |time|   cat   |  name  |
+++-++
| 1  | 2006-07-20 | ibm | zero1  |
| 2  | 2006-07-20 | ibm | spawn  |
| 3  | 2006-07-20 | ibm | spawn_multiple |
| 9  | 2006-07-20 | imb | range  |
| 12 | 2006-07-20 | imb | sub|

[snip] ...

* Failed Test Details

[1]

environment: foo = bar
test_command: mpirun -np 2 --prefix
/workspace/em162155/hpc/mtt/trunk/installs/ompi-nightly-v1.0/solaris_i386/install
./zero1
stderr: blah blah blah
stdout: blah blah blah

[2]

environment: foo = bar
test_command: mpirun -np 2 --prefix
/workspace/em162155/hpc/mtt/trunk/installs/ompi-nightly-v1.0/solaris_i386/install
./spawn
stderr: blah blah blah
stdout: blah blah blah

[snip] ...

==

* Passed Test Run(s)

os_version: SunOS 5.10
platform_hardware: i86pc
platform_id: Sun's Cluster
mpi_name: ompi-nightly-v1.0
mpi_version: 1.0.3a1r10793

+++-+-+
|  # |time|   cat   |  name   |
+++-+-+
|  3 | 2006-07-17 | trivial | f77_hello   |
| 32 | 2006-07-20 | ibm | allgatherv_in_place |
| 33 | 2006-07-20 | ibm | allreduce   |
| 34 | 2006-07-20 | ibm | allreduce_in_place  |
| 35 | 2006-07-20 | ibm | alltoall|
| 36 | 2006-07-20 | intel   | alltoallw   |
| 37 | 2006-07-20 | intel   | barrier |
| 38 | 2006-07-20 | intel   | bcast   |
| 39 | 2006-07-20 | imb | bcast_struct|
| 40 | 2006-07-20 | imb | exscan

Re: [MTT users] New stuff

[Ethan Mallove]

On Thu, Sep/14/2006 05:20:23PM, Josh Hursey wrote:
> Maybe I jumped the gun a bit, but I just updated and tried to run mtt  
> and get the following error message when I run:
> Reading ini file: /u/mpiteam/local/etc/ompi-iu-odin-core.ini
> *** WARNING: Could not read INI file:
>  /u/mpiteam/local/etc/ompi-iu-odin-core.ini; skipping
> 
> The file exists and was working previously. Any thoughts on why this  
> might happen?
> 

Never seen this one. I think I need more details. Could you do:

$ client/mtt -f file.ini | tee mtt.out
$ cat mtt.out
$ ls -l file.ini

I assume the mtt.out is very short if it's dying while trying to read the ini.

Thanks!

-Ethan


> Cheers,
> Josh
> 
> On Sep 14, 2006, at 2:53 PM, Jeff Squyres wrote:
> 
> > Howdy MTT users!
> >
> > We have a bunch of important updates for you, including some that  
> > *REQURE*
> > action tomorrow morning (15 Sep 2006: update your client and update  
> > your INI
> > files).  Please go read the full text of the announcement here:
> >
> > http://svn.open-mpi.org/trac/mtt/wiki/News-14-Sep-2006
> >
> > As usual, please let us know if you have any questions, comments,  
> > feedback,
> > etc.
> >
> > Thanks!
> >
> > -- 
> > 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
> 
> 
> Josh Hursey
> jjhur...@open-mpi.org
> http://www.open-mpi.org/
> 
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

Re: [MTT users] New stuff

[Ethan Mallove]

On Thu, Sep/14/2006 05:49:11PM, Josh Hursey wrote:
> After iterating a bit with Jeff. It seems that the error indicates  
> that I had a malformed ini file. I accidently left a bit of the old  
> script in there when I updated. :[
> 
> After removing that and doing a sanity check for other bits things  
> are working once again.
> 

For future reference, what was the malformation? If I had to
guess I'd say it was a missing '[' or ']' on a section
divider, a missing '=' or 'EOT' on a parameter assignment.

-Ethan


> Thanks :)
> 
> Josh
> 
> On Sep 14, 2006, at 5:36 PM, Josh Hursey wrote:
> 
> > Here you go:
> > [mpiteam@odin ~/mtt]$ ./client/mtt --mpi-get --mpi-install --scratch /
> > u/mpiteam/mtt-runs/Testing-09-14-2006-17-14-18 --file /u/mpiteam/
> > local/etc/ompi-iu-odin-core.ini --verbose --print-time --debug | tee
> > ~/mtt.out
> > Debug is 1, Verbose is 1
> > *** MTT: ./client/mtt --mpi-get --mpi-install --scratch
> > /u/mpiteam/mtt-runs/Testing-09-14-2006-17-14-18 --file
> > /u/mpiteam/local/etc/ompi-iu-odin-core.ini --verbose --print-time
> > --debug
> > Scratch: /u/mpiteam/mtt-runs/Testing-09-14-2006-17-14-18
> > Scratch resolved:
> > /san/homedirs/mpiteam/mtt-runs/Testing-09-14-2006-17-14-18
> > Making dir:
> > /san/homedirs/mpiteam/mtt-runs/Testing-09-14-2006-17-14-18/
> > sources (cwd:
> > /san/homedirs/mpiteam/mtt-runs/Testing-09-14-2006-17-14-18)
> > Making dir:
> > /san/homedirs/mpiteam/mtt-runs/Testing-09-14-2006-17-14-18/ 
> > installs
> > (cwd: /san/homedirs/mpiteam/mtt-runs/Testing-09-14-2006-17-14-18)
> > Reading ini file: /u/mpiteam/local/etc/ompi-iu-odin-core.ini
> > *** WARNING: Could not read INI file:
> >  /u/mpiteam/local/etc/ompi-iu-odin-core.ini; skipping
> >
> > [mpiteam@odin ~/mtt]$ cat ~/mtt.out
> > Debug is 1, Verbose is 1
> > *** MTT: ./client/mtt --mpi-get --mpi-install --scratch
> > /u/mpiteam/mtt-runs/Testing-09-14-2006-17-14-18 --file
> > /u/mpiteam/local/etc/ompi-iu-odin-core.ini --verbose --print-time
> > --debug
> > Scratch: /u/mpiteam/mtt-runs/Testing-09-14-2006-17-14-18
> > Scratch resolved:
> > /san/homedirs/mpiteam/mtt-runs/Testing-09-14-2006-17-14-18
> > Making dir:
> > /san/homedirs/mpiteam/mtt-runs/Testing-09-14-2006-17-14-18/
> > sources (cwd:
> > /san/homedirs/mpiteam/mtt-runs/Testing-09-14-2006-17-14-18)
> > Making dir:
> > /san/homedirs/mpiteam/mtt-runs/Testing-09-14-2006-17-14-18/ 
> > installs
> > (cwd: /san/homedirs/mpiteam/mtt-runs/Testing-09-14-2006-17-14-18)
> > Reading ini file: /u/mpiteam/local/etc/ompi-iu-odin-core.ini
> > *** WARNING: Could not read INI file:
> >  /u/mpiteam/local/etc/ompi-iu-odin-core.ini; skipping
> >
> > [mpiteam@odin ~/mtt]$ ls -l ~/local/etc/ompi-iu-odin-core.ini
> > -rw-r-  1 mpiteam projects 13741 Sep 14 17:01 /u/mpiteam/local/
> > etc/ompi-iu-odin-core.ini
> >
> > On Sep 14, 2006, at 5:33 PM, Ethan Mallove wrote:
> >
> >> On Thu, Sep/14/2006 05:20:23PM, Josh Hursey wrote:
> >>> Maybe I jumped the gun a bit, but I just updated and tried to run  
> >>> mtt
> >>> and get the following error message when I run:
> >>> Reading ini file: /u/mpiteam/local/etc/ompi-iu-odin-core.ini
> >>> *** WARNING: Could not read INI file:
> >>>  /u/mpiteam/local/etc/ompi-iu-odin-core.ini; skipping
> >>>
> >>> The file exists and was working previously. Any thoughts on why this
> >>> might happen?
> >>>
> >>
> >> Never seen this one. I think I need more details. Could you do:
> >>
> >> $ client/mtt -f file.ini | tee mtt.out
> >> $ cat mtt.out
> >> $ ls -l file.ini
> >>
> >> I assume the mtt.out is very short if it's dying while trying to
> >> read the ini.
> >>
> >> Thanks!
> >>
> >> -Ethan
> >>
> >>
> >>> Cheers,
> >>> Josh
> >>>
> >>> On Sep 14, 2006, at 2:53 PM, Jeff Squyres wrote:
> >>>
> >>>> Howdy MTT users!
> >>>>
> >>>> We have a bunch of important updates for you, including some that
> >>>> *REQURE*
> >>>> action tomorrow morning (15 Sep 2006: update your client and update
> >>>> your INI
> >>>> files).  Please go read the full text of the announcement here:
> >>>>
> >>>> http://svn.open-mpi.org/trac/mt

[MTT users] &shell funclet with stderr

[Ethan Mallove]

I finally got the &shell funclet to grab the Sun Studio compiler
version.  The below one worked from the shell, but not in the mtt
client (because the cc -V output goes to stderr?). 

compiler_version = &shell("cc -V |& head -n 1 | nawk '{print \$4}'");

The workaround was to have the 'cc -V' output and the head/nawk
utilities rendezvous in a file instead of a pipe.

compiler_version = &shell("cc -V 2> /tmp/cc.out; cat /tmp/cc.out | head -n 1 | 
nawk '{print \$4}'");

-Ethan

[MTT users] How goes the MTT?

[Ethan Mallove]

Folks,

Just checking in with everyone on how the new client is working out
for you. Any feature requests and/or bugs for the client and/or
reports? I see submissions from HLRS and IU, so I am assuming things
are working (to some degree). Do keep us apprised of any issues,
observations, complaints, etc.

Thanks!

-Ethan

Re: [MTT users] Timeouts for specific tests

[Ethan Mallove]

Not sure if this will work, but here goes (correct me if I'm
wrong, Jeff).

Try appending the following to the intel section of your ini (put
the names of the tests you expect to take 5 min, in a file named
'supposed_to_take_5_min' next to your other test lists):

simple_timeout:tests = &find_executables("src/" . 
"&cat("supposed_to_take_5_min")")
simple_timeout:np = &env_max_procs()
simple_timeout:timeout = 300
simple_timeout:exclusive = 1

-Ethan

On Wed, Sep/20/2006 01:04:55PM, Josh Hursey wrote:
> Is it possible to specify a timeout for a specific test in a test  
> suite in addition to the test suite as a whole?
> 
> For example some of the Intel tests take about 6 minutes to complete  
> normally, but the rest of the tests usually finish in a minute or so.  
> I'd like to keep the 1 min tests from waiting 6 min when they fail.
> 
> Just trying to tune our runs a bit here at IU. Not a bit deal if it  
> can't at the moment.
> 
> Cheers,
> Josh
> 
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

Re: [MTT users] Post run result submission

[Ethan Mallove]

On Tue, Sep/26/2006 02:01:41PM, Josh Hursey wrote:
> I'm setting up MTT on BigRed at IU, and due to some visibility  
> requirements of the compute nodes I segment the MTT operations.  
> Currently I have a perl script that does all the svn and wget  
> interactions from the login node, then compiles and runs on the  
> compute nodes. This all seems to work fine.
> 
> Now I am wondering how to get the textfile results that were  
> generated back to the MTT database once the run has finished.
> 

If you run the "MPI Install", "Test build", and "Test run"
sections from the same machine (call it the
"Install-Build-Run" node), I would think you could then
additionaly run the "Reporter: IU Database" section. Or can
you not do the HTTP POST from Install-Build-Run node? 

-Ethan

> I know HLRS deals with this situation, is there a supported way of  
> doing this yet or is it a future work item still?
> 
> Currently I have a method to send a summary email to our team after  
> the results are generated, so this isn't a show stopper for IU or  
> anything, just something so we can share our results with the rest of  
> the team.
> 
> Cheers,
> Josh
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

Re: [MTT users] Post run result submission

[Ethan Mallove]

I've posted the helper script here:

http://svn.open-mpi.org/trac/mtt/wiki/SubmitHelper

Let me know how it works.

-Ethan


On Tue, Sep/26/2006 04:06:01PM, Jeff Squyres wrote:
> For the moment, that might be sufficient.
> 
> What HLRS does is open ssh tunnels back to the head node and then http put's
> through those back to the IU database.  Icky, but it works.
> 
> The problem is that there are some other higher-priority items that we need
> to get done in MTT (performane measurements, for example) that, since there
> are [icky] workarounds for http puts, we put the whole "disconnected
> scenario" stuff at a lower priority.  :-(
> 
> 
> On 9/26/06 3:51 PM, "Ethan Mallove"  wrote:
> 
> > I have an unpretty solution that maybe could serve as a
> > stopgap between now and when we implement the "disconnected
> > scenarios" feature.  I have a very simple and easy-to-use
> > perl script that just HTTP POSTs a debug file (what *would*
> > have gone to the database). E.g.,
> > 
> > $ ./poster.pl -f 'mttdatabase_debug*.txt'
> > 
> > (Where mttdatabase_debug would be what you supply to the
> > mttdatabase_debug_filename ini param in the "IU Database"
> > section.)
> > 
> > I think this would fill in your missing * step below.
> > 
> > Does that sound okay, Jeff?
> > 
> > -Ethan
> > 
> > 
> > On Tue, Sep/26/2006 03:25:08PM, Josh Hursey wrote:
> >> So the login node is the only one that has a window to the outside
> >> world. I can't access the outside world from within an allocation.
> >> 
> >> So my script does:
> >>   - Login Node:
> >> 1) Get MPI Tarballs
> >>   - 1 Compute node:
> >> 0) Allocate a compute node to compile.
> >> 1) Build/Install MPI builds
> >> 2) Deallocate compute node
> >>   - Login Node:
> >> 1) Get MPI Test sources
> >>   - N Compute Nodes:
> >> 0) Allocate N compute Nodes to run the tests on
> >> 1) Build/Install Tests
> >> 2) Run the tests...
> >>   - Login Node:
> >> 0) Check to make sure we are all done (scheduler didn't kill the
> >>job, etc.).
> >> 1) Report results to MTT *
> >> 
> >> * This is what I am missing currently.
> >> 
> >> I currently have the "Reporter: IU Database" section commented out so
> >> that once the tests finish they don't try to post the database, since
> >> they can't see the outside world.
> >> 
> >> On Sep 26, 2006, at 3:17 PM, Ethan Mallove wrote:
> >> 
> >>> On Tue, Sep/26/2006 02:01:41PM, Josh Hursey wrote:
> >>>> I'm setting up MTT on BigRed at IU, and due to some visibility
> >>>> requirements of the compute nodes I segment the MTT operations.
> >>>> Currently I have a perl script that does all the svn and wget
> >>>> interactions from the login node, then compiles and runs on the
> >>>> compute nodes. This all seems to work fine.
> >>>> 
> >>>> Now I am wondering how to get the textfile results that were
> >>>> generated back to the MTT database once the run has finished.
> >>>> 
> >>> 
> >>> If you run the "MPI Install", "Test build", and "Test run"
> >>> sections from the same machine (call it the
> >>> "Install-Build-Run" node), I would think you could then
> >>> additionaly run the "Reporter: IU Database" section. Or can
> >>> you not do the HTTP POST from Install-Build-Run node?
> >>> 
> >>> -Ethan
> >>> 
> >>>> I know HLRS deals with this situation, is there a supported way of
> >>>> doing this yet or is it a future work item still?
> >>>> 
> >>>> Currently I have a method to send a summary email to our team after
> >>>> the results are generated, so this isn't a show stopper for IU or
> >>>> anything, just something so we can share our results with the rest of
> >>>> the team.
> >>>> 
> >>>> Cheers,
> >>>> Josh
> >>>> ___
> >>>> mtt-users mailing list
> >>>> mtt-us...@open-mpi.org
> >>>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
> >> 
> >> ___
> >> mtt-users mailing list
> >> mtt-us...@open-mpi.org
> >> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
> 
> 
> -- 
> Jeff Squyres
> Server Virtualization Business Unit
> Cisco Systems

Re: [MTT users] Post run result submission

[Ethan Mallove]

Ah, you're using the ''other'' .txt output file (from the [Reporter: write to
text file] section).

In the "Reporter: IU" section of the ini, there's a mttdatabase_debug_filename 
param. Mine is set like so:

mttdatabase_debug_filename = &shell("echo mttdatabase_debug.`hostname`")

So in my mtt workspace I have a bunch of these after an MTT run, e.g.,:

...
mttdatabase_debug.burl-ct-v440-2.5.txt
mttdatabase_debug.burl-ct-v440-2.6.txt
mttdatabase_debug.burl-ct-v440-2.7.txt
mttdatabase_debug.burl-ct-v440-2.8.txt
mttdatabase_debug.burl-ct-v440-2.9.txt
...

poster.pl expects one of these files. (The difference between the
two is a little subtle. The mttdatabase_debug files contain a 
ready to be eval'd perl variable, which poster.pl can use.)

-Ethan


On Thu, Sep/28/2006 02:50:43PM, Josh Hursey wrote:
> Finally getting a chance to try this out.
> 
> I am trying to use the script as perscribed on the webpage and am  
> getting some errors apparently from the 'eval $buf;' on line 39:
> m
> mpiteam@BigRed:> ./local/bin/post-mtt-results.pl -d -f bigred- 
> Test_Build-trivial-ompi-nightly-trunk-1.3a1r11860.txt
> Number found where operator expected at (eval 8) line 3, near "Linux  
> 2.6.5"
>  (Do you need to predeclare Linux?)
> Number found where operator expected at (eval 8) line 6, near "28 14"
>  (Missing operator before  14?)
> Number found where operator expected at (eval 8) line 6, near "30 2006"
>  (Missing operator before  2006?)
> Bareword found where operator expected at (eval 8) line 7, near "2006
> submit_test_timestamp"
>  (Missing operator before submit_test_timestamp?)
> Number found where operator expected at (eval 8) line 7, near "28 14"
>  (Missing operator before  14?)
> Number found where operator expected at (eval 8) line 7, near "40 2006"
>  (Missing operator before  2006?)
> Bareword found where operator expected at (eval 8) line 8, near "2006
> submitting_local_username"
>  (Missing operator before submitting_local_username?)
> Bareword found where operator expected at (eval 8) line 11, near "3.3.3
> mpi_get_section_name"
>  (Missing operator before mpi_get_section_name?)
> Bareword found where operator expected at (eval 8) line 14, near  
> "1.3a1r11860"
>  (Missing operator before a1r11860?)
> Bareword found where operator expected at (eval 8) line 16, near "6
> perfbase_xml"
>  (Missing operator before perfbase_xml?)
> Number found where operator expected at (eval 8) line 19, near "28 14"
>  (Missing operator before  14?)
> Number found where operator expected at (eval 8) line 19, near "37 2006"
>  (Missing operator before  2006?)
> Bareword found where operator expected at (eval 8) line 20, near "2006
> success"
>  (Missing operator before success?)
> Bareword found where operator expected at (eval 8) line 21, near "1
> test_build_section_name"
>  (Missing operator before test_build_section_name?)
> Bareword found where operator expected at (eval 8) line 22, near "3  
> seconds"
>  (Missing operator before seconds?)
> posting the following:
> hostname: s9c4b2
> os_name: Linux
> os_version: Linux 2.6.5-7.276-pseries64
> platform_hardware: ppc64
> platform_type: linux-sles9-ppc64
> start_run_timestamp: Thu Sep 28 14:56:30 2006
> submit_test_timestamp: Thu Sep 28 14:56:40 2006
> submitting_local_username: mpiteam
> compiler_name: gnu
> compiler_version: 3.3.3
> mpi_get_section_name: ompi-nightly-trunk
> mpi_install_section_name: bigred gcc warnings
> mpi_name: ompi-nightly-trunk
> mpi_version: 1.3a1r11860
> mtt_version_minor: 6
> perfbase_xml: inp_test_build.xml
> phase: Test Build
> result_message: Success
> start_test_timestamp: Thu Sep 28 14:56:37 2006
> success: 1
> test_build_section_name: trivial
> test_duration_interval: 3 seconds
> to http://www.open-mpi.org/mtt/submit/index.php
> Need a field name at (eval 10) line 1
> mmm
> 
> On Sep 26, 2006, at 6:26 PM, Ethan Mallove wrote:
> 
> > I've posted the helper script here:
> >
> > http://svn.open-mpi.org/trac/mtt/wiki/SubmitHelper
> >
> > Let me know how it works.
> >
> > -Ethan
> >
> >
> > On Tue, Sep/26/2006 04:06:01PM, Jeff Squyres wrote:
> >> For the moment, that might be sufficient.
> >>
> >> What HLRS does is open ssh tunnels back to the head node and then  
> >> http put's
> >> through those back t

Re: [MTT users] Post run result submission

[Ethan Mallove]

On Thu, Sep/28/2006 03:46:38PM, Josh Hursey wrote:
> So I have a section that looks like:
> 
> [Reporter: IU database]
> module = MTTDatabase
> 

I prefer this:

> mttdatabase_realm = OMPI
> mttdatabase_url = https://www.open-mpi.org/mtt/submit/
> # OMPI Core: Change this to be the username and password for your
> # submit user.  Get this from the OMPI MTT administrator.
> mttdatabase_username = username
> mttdatabase_password = password
> # OMPI Core: Change this to be some short string identifying your
> # cluster.
> mttdatabase_platform = TESTING BigRed at IU (mx,sm,self)
> mttdatabase_debug_filename = &shell("echo mttdatabase_debug.bigred")
> 
> 
> or should it just be:
> 
> [Reporter: IU database]
> mttdatabase_debug_filename = &shell("echo mttdatabase_debug.bigred")
> 
> 

That reminds me, I forgot to have a -u and -p options to poster.pl
(username and password). I added it to the wiki.

-Ethan
> 
> On Sep 28, 2006, at 3:38 PM, Ethan Mallove wrote:
> 
> >Ah, you're using the ''other'' .txt output file (from the  
> >[Reporter: write to
> >text file] section).
> >
> >In the "Reporter: IU" section of the ini, there's a  
> >mttdatabase_debug_filename
> >param. Mine is set like so:
> >
> >mttdatabase_debug_filename = &shell("echo  
> >mttdatabase_debug.`hostname`")
> >
> >So in my mtt workspace I have a bunch of these after an MTT run,  
> >e.g.,:
> >
> >...
> >mttdatabase_debug.burl-ct-v440-2.5.txt
> >mttdatabase_debug.burl-ct-v440-2.6.txt
> >mttdatabase_debug.burl-ct-v440-2.7.txt
> >mttdatabase_debug.burl-ct-v440-2.8.txt
> >mttdatabase_debug.burl-ct-v440-2.9.txt
> >...
> >
> >poster.pl expects one of these files. (The difference between the
> >two is a little subtle. The mttdatabase_debug files contain a
> >ready to be eval'd perl variable, which poster.pl can use.)
> >
> >-Ethan
> >
> >
> >On Thu, Sep/28/2006 02:50:43PM, Josh Hursey wrote:
> >>Finally getting a chance to try this out.
> >>
> >>I am trying to use the script as perscribed on the webpage and am
> >>getting some errors apparently from the 'eval $buf;' on line 39:
> >>m
> >>mpiteam@BigRed:> ./local/bin/post-mtt-results.pl -d -f bigred-
> >>Test_Build-trivial-ompi-nightly-trunk-1.3a1r11860.txt
> >>Number found where operator expected at (eval 8) line 3, near "Linux
> >>2.6.5"
> >> (Do you need to predeclare Linux?)
> >>Number found where operator expected at (eval 8) line 6, near "28 14"
> >> (Missing operator before  14?)
> >>Number found where operator expected at (eval 8) line 6, near "30  
> >>2006"
> >> (Missing operator before  2006?)
> >>Bareword found where operator expected at (eval 8) line 7, near "2006
> >>submit_test_timestamp"
> >> (Missing operator before submit_test_timestamp?)
> >>Number found where operator expected at (eval 8) line 7, near "28 14"
> >> (Missing operator before  14?)
> >>Number found where operator expected at (eval 8) line 7, near "40  
> >>2006"
> >> (Missing operator before  2006?)
> >>Bareword found where operator expected at (eval 8) line 8, near "2006
> >>submitting_local_username"
> >> (Missing operator before submitting_local_username?)
> >>Bareword found where operator expected at (eval 8) line 11, near  
> >>"3.3.3
> >>mpi_get_section_name"
> >> (Missing operator before mpi_get_section_name?)
> >>Bareword found where operator expected at (eval 8) line 14, near
> >>"1.3a1r11860"
> >> (Missing operator before a1r11860?)
> >>Bareword found where operator expected at (eval 8) line 16, near "6
> >>perfbase_xml"
> >> (Missing operator before perfbase_xml?)
> >>Number found where operator expected at (eval 8) line 19, near "28  
> >>14"
> >> (Missing operator before  14?)
> >>Number found where operator expected at (eval 8) line 19, near "37  
> >>2006"
> >> (Missing operator before  2006?)
> >>Bareword found where operator expected at (eval 8) line 20, near  
> >>"2006
> >>success"
> >> (Missing operator before success?)
> >>Bareword found where operator expected at (eval 8) line 21, 

Re: [MTT users] [MTT bugs] [MTT] #85: Some sites still returning &shell(...) for compiler version

[Ethan Mallove]

Hi Sven,

We noticed that mtt seems to not be grabbing the icc version
string in your results. E.g., we see this ugliness in the
HTML reports:

  &shell("icc -v 2>&1 | awk '{ print \$2 }'")

Unfortunately, I do not have access to an icc. Could you do
the following commands from a Bourne shell, to see if we can
get to the bottom of this?

$ icc -v 2>&1
$ icc -v

Thanks,
Ethan


On Mon, Oct/02/2006 07:23:43PM, MTT wrote:
> #85: Some sites still returning &shell(...) for compiler version
> -+--
>  Reporter:  jsquyres |   Owner:  emallove
>  Type:  defect   |  Status:  new 
>  Priority:  major|   Milestone:  v1.1
> Component:  Client side  | Version:  trunk   
>  Keywords:   |  
> -+--
>  Need to figure out why this is happening.
> 
>  Have they just not upgraded to latest release version, or something wrong
>  in their INI file, or ...?
> 
> -- 
> Ticket URL: 
> MTT 
> Issue tracking for the MPI Testing Tool.

> ___
> mtt-bugs mailing list
> mtt-b...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-bugs

[MTT users] Multiple scratch dirs needed?

[Ethan Mallove]

I do not have an instance of the string 'sparc' in my ini file,
yet I see the following in the --debug output. It looks like it's
running with every MPI Install that it can find in my scratch
dir. Do I need separate scratch trees for the two different
hardware platforms?

 >> Running with [ompi-nightly-v1.0] / [1.0.3a1r11129] / [solaris i386]
 >> Running with [ompi-nightly-trunk] / [1.3a1r11943] / [solaris i386]
 >> Running with [ompi-nightly-trunk] / [1.3a1r11943] / [solaris sparc 32]
 >> Running with [ompi-nightly-trunk] / [1.3a1r11962] / [solaris sparc 32]
 >> Running with [ompi-nightly-trunk] / [1.3a1r11929] / [solaris sparc]
 >> Running with [ompi-nightly-trunk] / [1.3a1r11929] / [solaris i386]
 >> Running with [ompi-nightly-trunk] / [1.3a1r11929] / [solaris sparc 32]
 >> Running with [ompi-nightly-v1.0] / [1.0.3a1r11129] / [solaris sparc]
 >> Running with [ompi-nightly-v1.0] / [1.0.3a1r11129] / [solaris sparc 2]
 >> Running with [ompi-nightly-v1.0] / [1.0.3a1r11129] / [solaris i386]
 >> Running with [ompi-nightly-trunk] / [1.3a1r11943] / [solaris i386]
 >> Running with [ompi-nightly-trunk] / [1.3a1r11943] / [solaris sparc 32]
 >> Running with [ompi-nightly-trunk] / [1.3a1r11962] / [solaris sparc 32]
 >> Running with [ompi-nightly-trunk] / [1.3a1r11929] / [solaris sparc]

-Ethan

Re: [MTT users] FW: [mtt-results] Nightly Test Build Failures

[Ethan Mallove]

On Thu, Oct/05/2006 09:09:38AM, Jeff Squyres wrote:
> Some of these are the usual "IBM isn't being recorded
> properly".  But a whole bunch of them are wrong ELF
> classes reported by Sun builds -- is this a symptom of
> sharing scratch directories?

Yes, 'wrong ELF classes' is a SPARC binary run on i386 or
vice versa.

> 
> I suspect that you need to whack your current scratch dir
> and then start tonight with at least 2 new scratch
> directories.  More specifically, you need a scratch
> directory for each MTT invocation that you run.
>

So this also underlines the importance of the Trim phase
that I was not seeing, because it means that if, e.g.,
1.2a1r11852 is still in the scratch tree - it will get run
every night if it's not removed. So we can rm -rf the
whole tree, but then we can't go back and rerun what we're
interested in. Right?

I think I also may have something for the wishlist. It would
be awesome if there was an option to tell mtt to only run
what is in the ini file. That would eliminate the need for
multiple scratch trees (which must be set manually). So a
--non-recursive (?) option or something, that tells mtt to
not walk the scratch directory and run everything it finds.
Or does this defeat the purpose of something I'm not seeing?

-Ethan


> -- 
> Jeff Squyres
> Server Virtualization Business Unit
> Cisco Systems
> 
> -- Forwarded Message
> > From: 
> > Reply-To: 
> > Date: Thu, 5 Oct 2006 09:00:30 -0400
> > To: 
> > Subject: [mtt-results] Nightly Test Build Failures
> > 
> > A plain text version of the Nightly MTT Test Results is not yet available.
> > Sorry.
> 
> -- End of Forwarded Message

Re: [MTT users] [mtt-results] Nightly Test Build Failures

[Ethan Mallove]

On Thu, Oct/05/2006 12:26:56PM, Jeff Squyres wrote:
> On 10/5/06 11:28 AM, "Ethan Mallove"
>  wrote:
> 
> >> Some of these are the usual "IBM isn't being recorded
> >> properly".  But a whole bunch of them are wrong ELF
> >> classes reported by Sun builds -- is this a symptom of
> >> sharing scratch directories?
> > 
> > Yes, 'wrong ELF classes' is a SPARC binary run on i386
> > or vice versa.
> 
> K.
>   
> >> I suspect that you need to whack your current scratch
> >> dir and then start tonight with at least 2 new scratch
> >> directories.  More specifically, you need a scratch
> >> directory for each MTT invocation that you run.
> > 
> > So this also underlines the importance of the Trim phase
> > that I was not seeing, because it means that if, e.g.,
> > 1.2a1r11852 is still in the scratch tree - it will get
> > run every night if it's not removed. So we can rm -rf
> > the whole tree, but then we can't go back and rerun what
> > we're interested in. Right?
> 
> No, it *shouldn't* be runing every night (in my tests,
> things are not run multiple times, but there is some
> current bug about this because Terry is seeing things run
> multiple times).  But yes, this underscores the need for
> the trim phase.
>  
> > I think I also may have something for the wishlist. It
> > would be awesome if there was an option to tell mtt to
> > only run what is in the ini file. That would eliminate
> > the need for multiple scratch trees (which must be set
> > manually). So a --non-recursive (?) option or something,
> > that tells mtt to not walk the scratch directory and run
> > everything it finds.  Or does this defeat the purpose of
> > something I'm not seeing?
> 
> It does only run what's in the INI file.  But if you have
> a) two MTT's sharing a common scratch, unpredictable
> things can happen with the XML meta data files in there
> (i.e., I don't do anything to guarantee atomic access and
> updates, etc.).  Or b) if you have older versions of stuff
> in your INI file that somehow are not accounted for
> properly in the XML data files, it could try to run them
> again.
>

I should delete my scratch area after any change to the ini?
With the Trim phase in place, this wouldn't be necessary?

-Ethan


> -- 
> Jeff Squyres
> Server Virtualization Business Unit
> Cisco Systems

[MTT users] --[no]-section filter

[Ethan Mallove]

Folks,

I just committed a handy --[no]-section command-line option.
It's documented here:

http://svn.open-mpi.org/trac/mtt/wiki/SectionFilter

Cheers,
Ethan

[MTT users] Tests build, but do not run

[Ethan Mallove]

My intel tests compile okay, but then do not run.
Here's the salient --debug output:

...
>> Test build [test build: intel sparc 32]
Evaluating: intel
   Building for [ompi-nightly-v1.2] / [1.2a1r12050] /
[solaris sparc 32] / [intel sparc 32]
Evaluating: Intel_OMPI_Tests
Making dir: tests (cwd:
/workspace/em162155/hpc/mtt/cron/ompi-core-testers/sparc/32/installs/ompi-nightly-v1.2/solaris_sparc_32/1.2a1r12050)
tests does not exist -- creating
Making dir: intel_sparc_32 (cwd:
/workspace/em162155/hpc/mtt/cron/ompi-core-testers/sparc/32/installs/ompi-nightly-v1.2/solaris_sparc_32/1.2a1r12050/tests)

...
OUT:[[[ END OF COMPILE ]]]
OUT:Compile complete. Log in all_tests_no_perf.12950.out
OUT:Start: Mon Oct  9 02:48:19 EDT 2006
OUT:End:   Mon Oct  9 03:05:28 EDT 2006
Command complete, exit status: 0
Writing built file:
/workspace/em162155/hpc/mtt/cron/ompi-core-testers/sparc/32/installs/ompi-nightly-v1.2/solaris_sparc_32/1.2a1r12050/tests/intel_sparc_32/intel_tests/test_built.ini
...
   Completed test build successfully
...
>> Test run [intel]
Evaluating: intel (how come no tests get run?)
>> Test run [ibm]

Is this because my "Test get" sections do not match my "Test
build" and "Test run" sections?

[Test get: intel]
[Test build: intel sparc 32]
[Test build: intel sparc 64]
[Test build: intel i386 32]
[Test build: intel i386 64]
[Test run: intel]

If so, it might be nice to get a "no match found" warning
of some kind.

-Ethan

Re: [MTT users] Tests build, but do not run

[Ethan Mallove]

To answer my own question, apparently Test Get/Build/Run
section labels must indeed match up
(http://svn.open-mpi.org/trac/mtt/wiki/MTTOverview).  To
work within these confines, I am instead breaking up my ini
file into several ini files (see below), and have created a
wrapper script to cat in only the specific platform/bitness
ini files I want to test.

  trunk.ini
  v1.0.ini
  v1.1.ini
  v1.2.ini
  ompi-core-template.ini
  build-intel-i386-32.ini
  build-intel-i386-64.ini
  build-intel-sparc-32.ini
  build-intel-sparc-64.ini
  mpi-install-i386-32.ini
  mpi-install-i386-64.ini
  mpi-install-sparc-32.ini
  mpi-install-sparc-64.ini
  reporter.ini

E.g.,

cat $mttdir/build-intel-$arch-$bit.ini " \
$mttdir/mpi-install-$arch-$bit.ini " \
$mttdir/ompi-core-template.ini " \
$mttdir/reporter.ini " \
$mttdir/$branch.ini " | \
client/mtt [...] 
--scratch ./$scratch " \
mttdatabase_platform='Sun $bit-bit' " \
mpi_get='ompi-nightly-$branch'

I think things were more manageable all in one file.  I
don't suppose there's an easy way to allow this using an ini
parameter (e.g., suite_name), versus the section name after
the ':'?

-Ethan



On Mon, Oct/09/2006 10:58:55AM, Ethan Mallove wrote:
> My intel tests compile okay, but then do not run.
> Here's the salient --debug output:
> 
> ...
> >> Test build [test build: intel sparc 32]
> Evaluating: intel
>Building for [ompi-nightly-v1.2] / [1.2a1r12050] /
> [solaris sparc 32] / [intel sparc 32]
> Evaluating: Intel_OMPI_Tests
> Making dir: tests (cwd:
> /workspace/em162155/hpc/mtt/cron/ompi-core-testers/sparc/32/installs/ompi-nightly-v1.2/solaris_sparc_32/1.2a1r12050)
> tests does not exist -- creating
> Making dir: intel_sparc_32 (cwd:
> /workspace/em162155/hpc/mtt/cron/ompi-core-testers/sparc/32/installs/ompi-nightly-v1.2/solaris_sparc_32/1.2a1r12050/tests)
> 
> ...
> OUT:[[[ END OF COMPILE ]]]
> OUT:Compile complete. Log in all_tests_no_perf.12950.out
> OUT:Start: Mon Oct  9 02:48:19 EDT 2006
> OUT:End:   Mon Oct  9 03:05:28 EDT 2006
> Command complete, exit status: 0
> Writing built file:
> /workspace/em162155/hpc/mtt/cron/ompi-core-testers/sparc/32/installs/ompi-nightly-v1.2/solaris_sparc_32/1.2a1r12050/tests/intel_sparc_32/intel_tests/test_built.ini
> ...
>Completed test build successfully
> ...
> >> Test run [intel]
> Evaluating: intel (how come no tests get run?)
> >> Test run [ibm]
> 
> Is this because my "Test get" sections do not match my "Test
> build" and "Test run" sections?
> 
> [Test get: intel]
> [Test build: intel sparc 32]
> [Test build: intel sparc 64]
> [Test build: intel i386 32]
> [Test build: intel i386 64]
> [Test run: intel]
> 
> If so, it might be nice to get a "no match found" warning
> of some kind.
> 
> -Ethan
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

[MTT users] Missing data

[Ethan Mallove]

I'm missing some data. I see the following in my --debug
output:

...
Build was a success
Evaluating: require MTT::Reporter::MTTDatabase
Evaluating: $ret =
&MTT::Reporter::MTTDatabase::Submit(@args)
MTTDatabase reporter
Submitting to MTTDatabase...
MTTDatabase submit complete
Writing to MTTDatabase debug file:
/workspace/em162155/hpc/mtt/cron/ompi-core-testers/sparc/32/trunk/mttdatabase_debug.burl-ct-v440-4.20061010.111631.0.txt
Debug MTTDatabase file write complete
>> 1 successful submit, 0 failed submits (total of 1 result)
   Completed MPI install successfully
*** MPI install phase complete
...

The debug file contains a success for a sparc/32-bit/trunk
MPI Install, but curiously this result doesn't seem to have
arrived in the 'mtt' db (around Tue Oct 10 15:48:39 2006).

mtt=> SELECT platform_hardware, os_name, mpi_name,
  mpi_version, platform_id, (CASE WHEN success='t' THEN
  'pass_case_installs' END) as pass, (CASE WHEN success='f'
  THEN 'fail_case_installs' END) as fail FROM installs JOIN
  once USING (run_index) WHERE start_test_timestamp >
  date_trunc('day', now()) AND os_name = 'SunOS';

 platform_hardware | os_name |  mpi_name  | mpi_version | platform_id 
|pass|fail
---+-++-+-++-
 i86pc | SunOS   | ompi-nightly-trunk | 1.3a1r12066 | Sun 32-bit  | 
   | 1
 i86pc | SunOS   | ompi-nightly-trunk | 1.3a1r12066 | Sun 64-bit  | 
   | 1
 i86pc | SunOS   | ompi-nightly-v1.2  | 1.2a1r12050 | Sun 32-bit  | 
1  |
 i86pc | SunOS   | ompi-nightly-v1.2  | 1.2a1r12050 | Sun 64-bit  | 
1  |
 sun4u | SunOS   | ompi-nightly-trunk | 1.3a1r12066 | Sun 64-bit  | 
   | 1
 sun4u | SunOS   | ompi-nightly-v1.2  | 1.2a1r12050 | Sun 64-bit  | 
1  |
 i86pc | SunOS   | ompi-nightly-trunk | 1.3a1r12069 | Sun 32-bit  | 
   | 1
 i86pc | SunOS   | ompi-nightly-trunk | 1.3a1r12069 | Sun 32-bit  | 
1  |
 i86pc | SunOS   | ompi-nightly-trunk | 1.3a1r12069 | Sun 64-bit  | 
1  |
 sun4u | SunOS   | ompi-nightly-trunk | 1.3a1r12069 | Sun 64-bit  | 
1  |
(10 rows)

mtt=> select timestamp without time zone 'now()';
 timestamp

 2006-10-10 14:06:22.251253
(1 row)

Note the missing sparc/32-bit/trunk result. Oddly, the Test
Builds and Test Runs for this submission did go through.
I've put in a request to get access to /var/log/pgsql to see
if I can see a failed INSERT.

-Ethan

Re: [MTT users] Missing data

[Ethan Mallove]

The problem is configure_arguments is not large enough to
hold:

--enable-debug --disable-mpi-f90
CC=cc CXX=CC FC=f90 F77=f77
CFLAGS="-xarch=v8plusa -xO5 -xmemalign=8s" 
CXXFLAGS="-xarch=v8plusa -xO5 -xmemalign=8s" 
FFLAGS="-xarch=v8plusa -xO5 -xmemalign=8s" 
FCFLAGS="-xarch=v8plusa -xO5 -xmemalign=8s -KPIC"

Though isn't the above only 245 characters long? Anyhow, do
we want an upper bound on this column?  I will make it an
unbound text for now (like stdout/stderr).

-Ethan


On Tue, Oct/10/2006 02:28:44PM, Ethan Mallove wrote:
> I'm missing some data. I see the following in my --debug
> output:
> 
> ...
> Build was a success
> Evaluating: require MTT::Reporter::MTTDatabase
> Evaluating: $ret =
> &MTT::Reporter::MTTDatabase::Submit(@args)
> MTTDatabase reporter
> Submitting to MTTDatabase...
> MTTDatabase submit complete
> Writing to MTTDatabase debug file:
> /workspace/em162155/hpc/mtt/cron/ompi-core-testers/sparc/32/trunk/mttdatabase_debug.burl-ct-v440-4.20061010.111631.0.txt
> Debug MTTDatabase file write complete
> >> 1 successful submit, 0 failed submits (total of 1 result)
>Completed MPI install successfully
> *** MPI install phase complete
> ...
> 
> The debug file contains a success for a sparc/32-bit/trunk
> MPI Install, but curiously this result doesn't seem to have
> arrived in the 'mtt' db (around Tue Oct 10 15:48:39 2006).
> 
> mtt=> SELECT platform_hardware, os_name, mpi_name,
>   mpi_version, platform_id, (CASE WHEN success='t' THEN
>   'pass_case_installs' END) as pass, (CASE WHEN success='f'
>   THEN 'fail_case_installs' END) as fail FROM installs JOIN
>   once USING (run_index) WHERE start_test_timestamp >
>   date_trunc('day', now()) AND os_name = 'SunOS';
> 
>  platform_hardware | os_name |  mpi_name  | mpi_version | platform_id 
> |pass|fail
> ---+-++-+-++-
>  i86pc | SunOS   | ompi-nightly-trunk | 1.3a1r12066 | Sun 32-bit  
> || 1
>  i86pc | SunOS   | ompi-nightly-trunk | 1.3a1r12066 | Sun 64-bit  
> || 1
>  i86pc | SunOS   | ompi-nightly-v1.2  | 1.2a1r12050 | Sun 32-bit  
> | 1  |
>  i86pc | SunOS   | ompi-nightly-v1.2  | 1.2a1r12050 | Sun 64-bit  
> | 1  |
>  sun4u | SunOS   | ompi-nightly-trunk | 1.3a1r12066 | Sun 64-bit  
> || 1
>  sun4u | SunOS   | ompi-nightly-v1.2  | 1.2a1r12050 | Sun 64-bit  
> | 1  |
>  i86pc | SunOS   | ompi-nightly-trunk | 1.3a1r12069 | Sun 32-bit  
> || 1
>  i86pc | SunOS   | ompi-nightly-trunk | 1.3a1r12069 | Sun 32-bit  
> | 1  |
>  i86pc | SunOS   | ompi-nightly-trunk | 1.3a1r12069 | Sun 64-bit  
> | 1  |
>  sun4u | SunOS   | ompi-nightly-trunk | 1.3a1r12069 | Sun 64-bit  
> | 1  |
> (10 rows)
> 
> mtt=> select timestamp without time zone 'now()';
>  timestamp
> 
>  2006-10-10 14:06:22.251253
> (1 row)
> 
> Note the missing sparc/32-bit/trunk result. Oddly, the Test
> Builds and Test Runs for this submission did go through.
> I've put in a request to get access to /var/log/pgsql to see
> if I can see a failed INSERT.
> 
> -Ethan
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

Re: [MTT users] Tests build, but do not run

[Ethan Mallove]

On Tue, Oct/10/2006 10:35:22PM, Jeff Squyres wrote:
> I'm not quite sure I understand the problem.  In each phase's section, you
> are supposed to identify the one (or more) predecessor phase sections.  For
> example, in MPI install phases, you specify an "mpi_get" field that
> indicates which MPI get phases should be built with this install section:
> 
> [MPI Get: foo]
> ...
> 
> [MPI Get: bar]
> 
> 
> [MPI Install: whatever]
> Mpi_get = foo,bar
> 
> The "whatever" MPI install section will build both the "foo" and "bar" MPI
> get sections.  This is also true with test get, build, and run phases.
> 
> [Test get: foo]
> ...
> 
> [Test build: bar]
> Test_get = foo
> 
> [test run: baz]
> Test_build = bar
> 
> These "back pointer" fields refer backwards to its parent/predecessor phase.
> They can also be comma-delimited lists of phase names (just like the
> "mpi_get" field in the MPI install phase) to help prevent duplication in the
> ini file.
> 
> So MTT does not assume or require that test get, build, and run phases all
> have the same base phase name (e.g., [test get: intel], [test build: intel],
> [test run: intel]).  You just have to link up names correctly with the
> corresponding "back pointer" field names.
> 
> Having said all that, does this make your problem easier?  I'm not entirely
> sure I understand the problem, so I'm not entirely sure that this is the
> answer.  :-)
> 
> 
> On 10/9/06 5:39 PM, "Ethan Mallove"  wrote:
> 
> > To answer my own question, apparently Test Get/Build/Run
> > section labels must indeed match up
> > (http://svn.open-mpi.org/trac/mtt/wiki/MTTOverview).  To
> > work within these confines, I am instead breaking up my ini
> > file into several ini files (see below), and have created a
> > wrapper script to cat in only the specific platform/bitness
> > ini files I want to test.
> > 
> >   trunk.ini
> >   v1.0.ini
> >   v1.1.ini
> >   v1.2.ini
> >   ompi-core-template.ini
> >   build-intel-i386-32.ini
> >   build-intel-i386-64.ini
> >   build-intel-sparc-32.ini
> >   build-intel-sparc-64.ini
> >   mpi-install-i386-32.ini
> >   mpi-install-i386-64.ini
> >   mpi-install-sparc-32.ini
> >   mpi-install-sparc-64.ini
> >   reporter.ini
> > 
> > E.g.,
> > 
> > cat $mttdir/build-intel-$arch-$bit.ini " \
> > $mttdir/mpi-install-$arch-$bit.ini " \
> > $mttdir/ompi-core-template.ini " \
> > $mttdir/reporter.ini " \
> > $mttdir/$branch.ini " | \
> > client/mtt [...] 
> > --scratch ./$scratch " \
> > mttdatabase_platform='Sun $bit-bit' " \
> > mpi_get='ompi-nightly-$branch'
> > 
> > I think things were more manageable all in one file.  I
> > don't suppose there's an easy way to allow this using an ini
> > parameter (e.g., suite_name), versus the section name after
> > the ':'?
> > 
> > -Ethan
> > 
> > 
> > 
> > On Mon, Oct/09/2006 10:58:55AM, Ethan Mallove wrote:
> >> My intel tests compile okay, but then do not run.
> >> Here's the salient --debug output:
> >> 
> >> ...
> >>>> Test build [test build: intel sparc 32]
> >> Evaluating: intel
> >>Building for [ompi-nightly-v1.2] / [1.2a1r12050] /
> >> [solaris sparc 32] / [intel sparc 32]
> >> Evaluating: Intel_OMPI_Tests
> >> Making dir: tests (cwd:
> >> /workspace/em162155/hpc/mtt/cron/ompi-core-testers/sparc/32/installs/ompi-nig
> >> htly-v1.2/solaris_sparc_32/1.2a1r12050)
> >> tests does not exist -- creating
> >> Making dir: intel_sparc_32 (cwd:
> >> /workspace/em162155/hpc/mtt/cron/ompi-core-testers/sparc/32/installs/ompi-nig
> >> htly-v1.2/solaris_sparc_32/1.2a1r12050/tests)
> >> 
> >> ...
> >> OUT:[[[ END OF COMPILE ]]]
> >> OUT:Compile complete. Log in all_tests_no_perf.12950.out
> >> OUT:Start: Mon Oct  9 02:48:19 EDT 2006
> >> OUT:End:   Mon Oct  9 03:05:28 EDT 2006
> >> Command complete, exit status: 0
> >> Writing built file:
> >> /workspace/em162155/hpc/mtt/cron/ompi-core-testers/sparc/32/installs/ompi-nig
> >> htly-v1.2/solaris_sparc_32/1.2a1r12050/tests/intel_sparc_32/intel_tests/test_
> >> built.ini
> >> ...
> >>Completed test build successfully
> >> ...
> >>>> Test run [intel]
> >> Evaluating: intel (how come no tests 

Re: [MTT users] Tests build, but do not run

[Ethan Mallove]

On Thu, Oct/12/2006 03:01:53PM, Jeff Squyres wrote:
> On Oct 11, 2006, at 11:34 AM, Ethan Mallove wrote:
> 
> >So if I do put the four combinations of platform/bitness in
> >a single ini file, I then have to do some ugly ini param
> >overriding to line up the sections, e.g.,:
> >
> >Command 1)
> >
> >$ cat /home/em162155/mtt/all.ini |
> > client/mtt  -p -d -
> >  [...]
> >   mpi_get='ompi-nightly-trunk'
> >   "intel:test_build='intel $arch $bit'"
> >   "imb:test_build='imb $arch $bit'"
> >   "ibm:test_build='ibm $arch $bit'"
> >   "trivial:test_build='trivial $arch $bit'"
> >
> >I was thinking it would be nice if I could do something
> >like this in my ini:
> >
> >[Test get: intel all]
> >suite_name = intel
> >[Test build: intel sparc 32]
> >suite_name = intel
> >[Test build: intel sparc 64]
> >suite_name = intel
> >[Test build: intel i386 32]
> >suite_name = intel
> >[Test build: intel i386 64]
> >suite_name = intel
> >[Test run: intel all]
> >suite_name = intel
> 
> Why do you need different test build sections?
>

Different intel_ompi_tests_(f|c)flags parameters for each.

-Ethan


> -- 
> Jeff Squyres
> Server Virtualization Business Unit
> Cisco Systems
> 

Re: [MTT users] MTT reporter module settings

[Ethan Mallove]

Hi Jim,

On Wed, Oct/18/2006 12:02:24PM, James W. Barker wrote:
> Ethan,
> 
> Do you know the correct values for the elements of the reporter 
> module of the MTT .ini file?  These are the values I currently have 
> set in my .ini file.
> 
> [Reporter: IU database]
> module = MTTDatabase
> 
> mttdatabase_realm = OMPI
> mttdatabase_url = https://www.open-mpi.org/mtt/submit/


Do you access the web through a proxy server? If so, you
need to set your http_proxy/https_proxy env var(s) to that
proxy.


> # OMPI Core: Change this to be the username and password for your
> # submit user.  Get this from the OMPI MTT administrator.
> mttdatabase_username = lanl
> mttdatabase_password = XXX


I take it you *do* know your password, but just didn't email
it to the list.


> # OMPI Core: Change this to be some short string identifying your
> # cluster.
> mttdatabase_platform = odin

This won't effect your connectivity with the mtt database,
but you probably want to do something like:

mttdatabase_platform = lanl

-Ethan

> 
> MTT reported it could not ping https://www.open-mpi.org/mtt/submit/, 
> what is the correct URL?  Is the mttdatabase_realm = OMPI?  Is the 
> mttdatabase_platform = odin?
> 
> Thanks,
> Jim Barker
> 
> 
> James W. Barker,  Ph.D.
> Los Alamos National Laboratory
> Computer, Computational and Statistical Sciences Division
> Advanced Computing Laboratory - Application Communications and 
> Performance Research Team
> 505-665-9558 
> 
> 
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

Re: [MTT users] Bproc support in MTT

[Ethan Mallove]

On Wed, Oct/18/2006 09:28:01AM, James W. Barker wrote:
> Ethan,
> 
> In an email exchange with Jeff Squyres regarding setting the number 
> of processors on a Bproc system the following statement was made:
> 
> Are you running under bproc or some other scheduler?  Right now, MTT 
> understands SLURM, Torque, and LoadLeveler.  If you're running under 
> Bproc, we can easily add support for it into MTT (I'll need some 
> information from you since I don't have any BProc systems myself).
> 
> Jeff went on to say:
> 
> Ethan Mallove is the engineer at Sun who is heading up most of the 
> MTT efforts these days; the mails go to all of us, so he can reply 
> even when I'm unavailable.
> 
> So I am asking what information do you need from me to add Bproc 
> support to MTT?
>

Are NODES and NODELIST the only env vars that BProc uses (I
gleaned this info from
http://asci-training.lanl.gov/BProc/)?

MTT is set up to detect environment variables and hostfiles
used by Slurm, PBS, N1GE, and LoadLeveler and set a max
value for -np based on those env vars.  While we add the
smarts to MTT to do that for BProc, you could also hardcode
the -np value (e.g., 2) in your ini's "MPI Details" section
like so:

exec = mpirun @hosts@ -np 2 --prefix &test_prefix() &test_executable() 
&test_argv()

Thanks,
Ethan


> Thanks,
> Jim Barker
> 
> James W. Barker,  Ph.D.
> Los Alamos National Laboratory
> Computer, Computational and Statistical Sciences Division
> Advanced Computing Laboratory - Application Communications and 
> Performance Research Team
> 505-665-9558 
> 
> 
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

Re: [MTT users] Bproc support in MTT

[Ethan Mallove]

Jim,

I'm not familiar with intel's built-in iteration over an 
array of -np values. MTT achieves this 'multiplicative'
effect via "funclets" in the INI file. E.g., 

np = &pow(2, 0, &log(2, 60))

So you would insert the above line in the [Test run: intel]
section of the INI file. More on the above "funclet"
mechanism in MTT here:

http://svn.open-mpi.org/trac/mtt/wiki/MTTOverview#Funclets

"... &pow returns an array of values from base^min_exponent
to base^max_exponent. So in the above "np" example, ... np
would be an array of the following values: 1, 2, 4, 8 16,
32."

-Ethan


On Thu, Oct/19/2006 12:07:42PM, James W. Barker wrote:
> Ethan,
> 
> I believe you are correct, $NODES and $NODELIST appear to be the only 
> environmental variables associated with BProc.  It would be nice if 
> MTT had the "smarts to ... do that for BProc".  However, before you 
> invest any effort in that; how do you currently increase the number 
> of processors per iteration for tests like the intel test suite?  You 
> can't simply set -np 2 or -np 32 because the intel test suite was 
> designed to iterate, squaring the number of processors each time the 
> suite is executed up to (I think) a maximum of 64 processors.
> 
> Thanks,
> Jim Barker
> 
> At 03:41 PM 10/18/2006, you wrote:
> >On Wed, Oct/18/2006 09:28:01AM, James W. Barker wrote:
> >> Ethan,
> >>
> >> In an email exchange with Jeff Squyres regarding setting the number
> >> of processors on a Bproc system the following statement was made:
> >>
> >> Are you running under bproc or some other scheduler?  Right now, MTT
> >> understands SLURM, Torque, and LoadLeveler.  If you're running under
> >> Bproc, we can easily add support for it into MTT (I'll need some
> >> information from you since I don't have any BProc systems myself).
> >>
> >> Jeff went on to say:
> >>
> >> Ethan Mallove is the engineer at Sun who is heading up most of the
> >> MTT efforts these days; the mails go to all of us, so he can reply
> >> even when I'm unavailable.
> >>
> >> So I am asking what information do you need from me to add Bproc
> >> support to MTT?
> >>
> >
> >Are NODES and NODELIST the only env vars that BProc uses (I
> >gleaned this info from
> >http://asci-training.lanl.gov/BProc/)?
> >
> >MTT is set up to detect environment variables and hostfiles
> >used by Slurm, PBS, N1GE, and LoadLeveler and set a max
> >value for -np based on those env vars.  While we add the
> >smarts to MTT to do that for BProc, you could also hardcode
> >the -np value (e.g., 2) in your ini's "MPI Details" section
> >like so:
> >
> >exec = mpirun @hosts@ -np 2 --prefix &test_prefix() 
> >&test_executable() &test_argv()
> >
> >Thanks,
> >Ethan
> >
> >
> >> Thanks,
> >> Jim Barker
> >>
> >> James W. Barker,  Ph.D.
> >> Los Alamos National Laboratory
> >> Computer, Computational and Statistical Sciences Division
> >> Advanced Computing Laboratory - Application Communications and
> >> Performance Research Team
> >> 505-665-9558
> >>
> >>
> >> ___
> >> mtt-users mailing list
> >> mtt-us...@open-mpi.org
> >> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
> 
> James W. Barker,  Ph.D.
> Los Alamos National Laboratory
> Computer, Computational and Statistical Sciences Division
> Advanced Computing Laboratory - Application Communications and 
> Performance Research Team
> 505-665-9558 
> 
> 

Re: [MTT users] MTT reporter module settings

[Ethan Mallove]

On Thu, Oct/19/2006 11:24:46AM, James W. Barker wrote:
> Ethan,
> 
> Using http I get the same error only on port 80 instead of port 
> 443.  See below:
> 
> ***WARNING: >> Failed test ping to MTTDatabase URL:
>   http://www.open-mpi.org:80/mtt/submit
> ***WARNING:  >> Error was:  400 Bad Request
> ERROR:
> Client version not specified.

"Client version not specified" is coming from the IU server,
so I believe I was getting off track with the http and
https. You are connecting, but you should be seeing:

"MTTDatabase testing submit URL with a ping...
MTTDatabase ping successful: 200 OK
   Ping successful."

The fact that you see "Client version not specified" tells
me there's no "PING" in the HTTP POST (the server thinks
you're sending test results, not a PING). Can you start up a
web browser from that same machine you're running mtt on,
and see if you run into an issue POSTing to any other web
site (e.g., google, yahoo, etc).

Does your svn info shows this?

https://svn.open-mpi.org/svn/mtt/branches/ompi-core-testers

-Ethan

> 
> I think the problem may be MTT literally appending the port number to 
> the URL (www.open-mpi.org:80  or  www.open-mpi.org:443).  That is 
> what I see when I run MTT in debug mode.  Is that possible?
> 
> Jim Barker
> 
> 
> At 10:11 AM 10/19/2006, you wrote:
> >On Thu, Oct/19/2006 09:48:08AM, James W. Barker wrote:
> >> Ethan,
> >>
> >> I now have the variables set in the Reporter as you indicated
> >> below.  However, I get the following error message when the reporter
> >> module initializes:
> >>
> >> ***WARNING: >> Failed test ping to MTTDatabase URL:
> >>  https://www.open-mpi.org:443/mtt/submit
> >> ***WARNING:  >> Error was:  400 Bad Request
> >> ERROR:
> >> Client version not specified.
> >>
> >> Any thoughts on what is causing this error?
> >>
> >
> >Did you try using http instead of https?
> >
> >-Ethan
> >
> >> Jim Barker
> >>
> >> At 03:28 PM 10/18/2006, you wrote:
> >> >Hi Jim,
> >> >
> >> >On Wed, Oct/18/2006 12:02:24PM, James W. Barker wrote:
> >> >> Ethan,
> >> >>
> >> >> Do you know the correct values for the elements of the reporter
> >> >> module of the MTT .ini file?  These are the values I currently have
> >> >> set in my .ini file.
> >> >>
> >> >> [Reporter: IU database]
> >> >> module = MTTDatabase
> >> >>
> >> >> mttdatabase_realm = OMPI
> >> >> mttdatabase_url = https://www.open-mpi.org/mtt/submit/
> >> >
> >> >
> >> >Do you access the web through a proxy server? If so, you
> >> >need to set your http_proxy/https_proxy env var(s) to that
> >> >proxy.
> >> >
> >> >
> >> >> # OMPI Core: Change this to be the username and password for your
> >> >> # submit user.  Get this from the OMPI MTT administrator.
> >> >> mttdatabase_username = lanl
> >> >> mttdatabase_password = XXX
> >> >
> >> >
> >> >I take it you *do* know your password, but just didn't email
> >> >it to the list.
> >> >
> >> >
> >> >> # OMPI Core: Change this to be some short string identifying your
> >> >> # cluster.
> >> >> mttdatabase_platform = odin
> >> >
> >> >This won't effect your connectivity with the mtt database,
> >> >but you probably want to do something like:
> >> >
> >> >mttdatabase_platform = lanl
> >> >
> >> >-Ethan
> >> >
> >> >>
> >> >> MTT reported it could not ping https://www.open-mpi.org/mtt/submit/,
> >> >> what is the correct URL?  Is the mttdatabase_realm = OMPI?  Is the
> >> >> mttdatabase_platform = odin?
> >> >>
> >> >> Thanks,
> >> >> Jim Barker
> >> >>
> >> >>
> >> >> James W. Barker,  Ph.D.
> >> >> Los Alamos National Laboratory
> >> >> Computer, Computational and Statistical Sciences Division
> >> >> Advanced Computing Laboratory - Application Communications and
> >> >> Performance Research Team
> >> >> 505-665-9558
> >> >>
> >> >>
> >> >> ___
> >> >> mtt-users mailing list
> >> >> mtt-us...@open-mpi.org
> >> >> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
> >>
> >> James W. Barker,  Ph.D.
> >> Los Alamos National Laboratory
> >> Computer, Computational and Statistical Sciences Division
> >> Advanced Computing Laboratory - Application Communications and
> >> Performance Research Team
> >> 505-665-9558
> >>
> >>
> 
> James W. Barker,  Ph.D.
> Los Alamos National Laboratory
> Computer, Computational and Statistical Sciences Division
> Advanced Computing Laboratory - Application Communications and 
> Performance Research Team
> 505-665-9558 
> 
> 

Re: [MTT users] MTT reporter module settings

[Ethan Mallove]

Ah, remove that trunk workspace, and checkout the release
branch:

$ svn co https://svn.open-mpi.org/svn/mtt/branches/ompi-core-testers

The trunk is out of service at the moment, while we're
implementing MTT 2.0 stuff in it.

-Ethan


On Fri, Oct/20/2006 03:53:24PM, James W. Barker wrote:
> Ethan,
> 
> Below is the output svn info generates:
> 
> ffe1.lanl.gov> svn info
> Path: .
> URL: https://svn.open-mpi.org/svn/mtt/trunk
> Repository Root: https://svn.open-mpi.org/svn/mtt
> Repository UUID: 3a00f1f0-e206-0410-aee5-9638c71ae14b
> Revision: 374
> Node Kind: directory
> Schedule: normal
> Last Changed Author: emallove
> Last Changed Rev: 374
> Last Changed Date: 2006-10-03 13:13:35 -0600 (Tue, 03 Oct 2006)
> 
> Jim Barker
> 
> At 08:14 AM 10/20/2006, you wrote:
> >On Thu, Oct/19/2006 11:24:46AM, James W. Barker wrote:
> >> Ethan,
> >>
> >> Using http I get the same error only on port 80 instead of port
> >> 443.  See below:
> >>
> >> ***WARNING: >> Failed test ping to MTTDatabase URL:
> >>   http://www.open-mpi.org:80/mtt/submit
> >> ***WARNING:  >> Error was:  400 Bad Request
> >> ERROR:
> >> Client version not specified.
> >
> >"Client version not specified" is coming from the IU server,
> >so I believe I was getting off track with the http and
> >https. You are connecting, but you should be seeing:
> >
> >"MTTDatabase testing submit URL with a ping...
> >MTTDatabase ping successful: 200 OK
> >   Ping successful."
> >
> >The fact that you see "Client version not specified" tells
> >me there's no "PING" in the HTTP POST (the server thinks
> >you're sending test results, not a PING). Can you start up a
> >web browser from that same machine you're running mtt on,
> >and see if you run into an issue POSTing to any other web
> >site (e.g., google, yahoo, etc).
> >
> >Does your svn info shows this?
> >
> >https://svn.open-mpi.org/svn/mtt/branches/ompi-core-testers
> >
> >-Ethan
> >
> >>
> >> I think the problem may be MTT literally appending the port number to
> >> the URL (www.open-mpi.org:80  or  www.open-mpi.org:443).  That is
> >> what I see when I run MTT in debug mode.  Is that possible?
> >>
> >> Jim Barker
> >>
> >>
> >> At 10:11 AM 10/19/2006, you wrote:
> >> >On Thu, Oct/19/2006 09:48:08AM, James W. Barker wrote:
> >> >> Ethan,
> >> >>
> >> >> I now have the variables set in the Reporter as you indicated
> >> >> below.  However, I get the following error message when the reporter
> >> >> module initializes:
> >> >>
> >> >> ***WARNING: >> Failed test ping to MTTDatabase URL:
> >> >>  https://www.open-mpi.org:443/mtt/submit
> >> >> ***WARNING:  >> Error was:  400 Bad Request
> >> >> ERROR:
> >> >> Client version not specified.
> >> >>
> >> >> Any thoughts on what is causing this error?
> >> >>
> >> >
> >> >Did you try using http instead of https?
> >> >
> >> >-Ethan
> >> >
> >> >> Jim Barker
> >> >>
> >> >> At 03:28 PM 10/18/2006, you wrote:
> >> >> >Hi Jim,
> >> >> >
> >> >> >On Wed, Oct/18/2006 12:02:24PM, James W. Barker wrote:
> >> >> >> Ethan,
> >> >> >>
> >> >> >> Do you know the correct values for the elements of the reporter
> >> >> >> module of the MTT .ini file?  These are the values I currently have
> >> >> >> set in my .ini file.
> >> >> >>
> >> >> >> [Reporter: IU database]
> >> >> >> module = MTTDatabase
> >> >> >>
> >> >> >> mttdatabase_realm = OMPI
> >> >> >> mttdatabase_url = https://www.open-mpi.org/mtt/submit/
> >> >> >
> >> >> >
> >> >> >Do you access the web through a proxy server? If so, you
> >> >> >need to set your http_proxy/https_proxy env var(s) to that
> >> >> >proxy.
> >> >> >
> >> >> >
> >> >> >> # OMPI Core: Change this to be the username and password for your
> >> >> >> # submit user.  Get this from the OMPI MTT administrator.
> >> >> >> mttdatabase_username = lanl
> >> >> >> mttdatabase_password = XXX
> >> >> >
> >> >> >
> >> >> >I take it you *do* know your password, but just didn't email
> >> >> >it to the list.
> >> >> >
> >> >> >
> >> >> >> # OMPI Core: Change this to be some short string identifying your
> >> >> >> # cluster.
> >> >> >> mttdatabase_platform = odin
> >> >> >
> >> >> >This won't effect your connectivity with the mtt database,
> >> >> >but you probably want to do something like:
> >> >> >
> >> >> >mttdatabase_platform = lanl
> >> >> >
> >> >> >-Ethan
> >> >> >
> >> >> >>
> >> >> >> MTT reported it could not ping 
> >https://www.open-mpi.org/mtt/submit/,
> >> >> >> what is the correct URL?  Is the mttdatabase_realm = OMPI?  Is the
> >> >> >> mttdatabase_platform = odin?
> >> >> >>
> >> >> >> Thanks,
> >> >> >> Jim Barker
> >> >> >>
> >> >> >>
> >> >> >> James W. Barker,  Ph.D.
> >> >> >> Los Alamos National Laboratory
> >> >> >> Computer, Computational and Statistical Sciences Division
> >> >> >> Advanced Computing Laboratory - Application Communications and
> >> >> >> Performance Research Team
> >> >> >> 505-665-9558
> >> >> >>
> >> >> >>
> >> >> >> ___
> >> >> >> mtt-users 

Re: [MTT users] Discussion on teleconf yesterday?

[Ethan Mallove]

On Wed, Oct/25/2006 10:37:31AM, Josh Hursey wrote:
> 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.

Sounds like summary.php does not suffice.

http://www.open-mpi.org/mtt/summary.php

One thought is that we've already iterated on the summary,
and my understanding was that the summary wasn't intended to
satisfy any one particular user's needs. By MTT 2.0, I think
Reporter should be flexible and usable enough to do that. Do
we need more summary pages? If various folks need more
specific reports than what summary.php provides, I'd be
happy to do the cut-n-paste into the nightly emailer to give
them those reports, while we get custom email alerts going
(in MTT 2.0 or whenever).


>  - 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].


Could some or all of print-results.pl (which was attached to
#61) be inserted into lib/MTT/Reporter/Email.pm, so that all
mtt users can use what you have (if they need something
similar to your email reports)? At first glance, it looks
like a lot of print-results.pl is generalized enough for
that.


>  - 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


http://svn.open-mpi.org/trac/mtt/ticket/70 (show "new"
failures) is also relevant for getting a quick and automated
info on what regressed/progressed last night.

-Ethan


> 
> 
> 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 Od

Re: [MTT users] Discussion on teleconf yesterday?

[Ethan Mallove]

On Fri, Oct/27/2006 10:31:44AM, Josh Hursey wrote:
> 
> On Oct 27, 2006, at 7:39 AM, Jeff Squyres wrote:
> 
> > On Oct 25, 2006, at 10:37 AM, Josh Hursey wrote:
> >
> >> The discussion started with the bug characteristics of v1.2 versus
> >> the trunk.
> >
> > Gotcha.
> >
> >> 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 'test...@open-mpi.org' list as a bandaid until
> >> MTT could do it better.
> >
> > How about sending them to me and Ethan?
> 
> Sure I can add you both to the list if you like.
> 
> >
> >> 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.
> >
> > Agreed; we aren't super-fond of the current web page, either.  Do you
> > guys want to have a teleconf to go over the current status of MTT,
> > where you want it to go, etc.?  I consider IU's input here quite
> > important, since you're the ones pushing the boundaries, flexing
> > MTT's muscles, etc.
> 
> In my previous email I suggested a couple of questions that I would  
> like a webpage to answer. A teleconf might be good to talk about some  
> of the various items that IU is trying to do around MTT.
> 
> >
> >> 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.
> >
> > Ok.
> >
> > We created another ticket yesterday to make a new MTT Reporter (our
> > internal plugins) that duplicates this output format.  It actually
> > shouldn't be that hard -- we don't have to do parsing to get the
> > numbers that you're reporting; we have access to the actual data.  So
> > it's mostly caching the data, calculating the totals that you're
> > calculating, and printing in your output format.
> >
> > Ethan has some other short tasks to do before he gets to this, but
> > its near the top of the priority list.  You can see the current
> > workflow on the wiki (this is a living document; it keeps changing as
> > requirements, etc. change):
> >
> >  http://svn.open-mpi.org/trac/mtt/wiki/TaskPlan
> >
> 
> Awesome Thanks! :)
> 
> >> 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.
> >
> > We have the summary.php page, but I personally have never found it
> > too useful.  :-)
> >
> > We're getting towards a full revamp of reporter.php (got some other
> > tasks to complete first, but we're definitely starting to think about
> > it) -- got any ideas / input?  Our "haven't thought about it much
> > yet" idea is to be more menu/Q-A driven with a few common queries
> > easily available (rather than a huge, complicated single screen).
> 
> See previous email for some general ideas. Tim M might have a few  
> more that he would like to see since he is the one at IU that is  
> watching the nightly results the closest.
> 
> >
> >>  - 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].
> 

Re: [MTT users] Discussion on teleconf yesterday? (raw SQL)

[Ethan Mallove]

FYI - in the open-mpi.org/mtt, you can check the "SQL"
checkbox to see the raw SQL queries. Here's the "Odin" query
showing the SQL:

http://tinyurl.com/yd7oob

You can modify and play around with those on the live
database, e.g.:

$ echo "... some SQL ... " | psql -d mtt -U iu

I also like the pg_dump command. E.g., view the live schema:

$ pg_dump -s -d mtt -U iu

-Ethan


> > 
> > Basically our problems are:
> >   - Testing results come in at various times as they complete, we  
> > would really like a 'status report' at 8 am every day finished or not.
> 
> For now, could you load up this webpage everyday at 8am?
> 
> http://tinyurl.com/ydt777
> 
> 

Re: [MTT users] [MTT svn] svn:mtt-svn r403

[Ethan Mallove]

I've run with these changes and they seem to work (I did
need to change the INI param "module" to "specify_module",
from the previous commit). Just one question (see below).


On Sun, Oct/29/2006 08:36:04AM, jsquy...@osl.iu.edu wrote:
> Author: jsquyres
> Date: 2006-10-29 08:35:58 EST (Sun, 29 Oct 2006)
> New Revision: 403
> 
> Modified:
>trunk/CHANGES
>trunk/lib/MTT/DoCommand.pm
>trunk/lib/MTT/Globals.pm
>trunk/samples/ompi-core-template.ini
> 
> Log:
>  * Add textwrap to Global defaults
>  * Add new global: drain_timeout
>  * In DoCommand, after the timeout, we'll wait drain_timeout more
>seconds to get any final output and then unconditionally move on.
>  * Add some Verbose statements to catch when kill() does not seem to
>be working.  Have not nailed this down yet; want to see some output
>from when it occurrs.
> 
> 
> Modified: trunk/CHANGES
> ==
> --- trunk/CHANGES (original)
> +++ trunk/CHANGES 2006-10-29 08:35:58 EST (Sun, 29 Oct 2006)
> @@ -1,2 +1,5 @@
>  To announce to OMPI core testers:
>  
> +- added new fields to MTT section to ini file
> +  - textwrap
> +  - drain_timeout
> 
> Modified: trunk/lib/MTT/DoCommand.pm
> ==
> --- trunk/lib/MTT/DoCommand.pm(original)
> +++ trunk/lib/MTT/DoCommand.pm2006-10-29 08:35:58 EST (Sun, 29 Oct 
> 2006)
> @@ -32,6 +32,7 @@
>  if ($kid != 0) {
>  return $?;
>  }
> +Verbose("** Kill TERM didn't work!\n");
>  
>  # Nope, that didn't work.  Sleep a few seconds and try again.
>  sleep(2);
> @@ -39,6 +40,7 @@
>  if ($kid != 0) {
>  return $?;
>  }
> +Verbose("** Kill TERM (more waiting) didn't work!\n");
>  
>  # That didn't work either.  Try SIGINT;
>  kill("INT", $pid);
> @@ -46,6 +48,7 @@
>  if ($kid != 0) {
>  return $?;
>  }
> +Verbose("** Kill INT didn't work!\n");
>  
>  # Nope, that didn't work.  Sleep a few seconds and try again.
>  sleep(2);
> @@ -53,6 +56,7 @@
>  if ($kid != 0) {
>  return $?;
>  }
> +Verbose("** Kill INT (more waiting) didn't work!\n");
>  
>  # Ok, now we're mad.  Be violent.
>  while (1) {
> @@ -61,13 +65,7 @@
>  if ($kid != 0) {
>  return $?;
>  }
> -sleep(1);
> -
> -kill("KILL", $pid);
> -$kid = waitpid($pid, WNOHANG);
> -if ($kid != 0) {
> -return $?;
> -}
> +Verbose("** Kill KILL didn't work!\n");
>  sleep(1);
>  }
>  }
> @@ -278,7 +276,7 @@
>  if (defined($end_time) && time() > $end_time) {
>  my $over = time() - $end_time;
>  if ($over > $last_over) {
> -Debug("*** Past timeout by $over seconds\n");
> +Verbose("*** Past timeout by $over seconds\n");
>  my $st = _kill_proc($pid);
>  if (!defined($killed_status)) {
>  $killed_status = $st;
> @@ -286,6 +284,12 @@
>  $ret->{timed_out} = 1;
>  }
>  $last_over = $over;
> +
> +# See if we've over the drain_timeout
> +if ($over > $MTT::Globals::Values->{drain_timeout}) {
> +Verbose("*** Past drain timeout; quitting\n");
> +$done = 0;
> +}


I would have thought if we're "quitting" here, then $done =
1.

-Ethan


>  }
>  }
>  close OUTerr;
> 
> Modified: trunk/lib/MTT/Globals.pm
> ==
> --- trunk/lib/MTT/Globals.pm  (original)
> +++ trunk/lib/MTT/Globals.pm  2006-10-29 08:35:58 EST (Sun, 29 Oct 2006)
> @@ -26,6 +26,8 @@
>  hostfile => undef,
>  hostlist => undef,
>  max_np => undef,
> +textwrap => 76,
> +drain_timeout => 5,
>  };
>  
>  # Reset $Globals per a specific ini file
> @@ -68,6 +70,13 @@
>  if ($val) {
>  $Values->{textwrap} = $val;
>  }
> +
> +# Output display preference
> +
> +my $val = MTT::Values::Value($ini, "MTT", "drain_timeout");
> +if ($val) {
> +$Values->{drain_timeout} = $val;
> +}
>  }
>  
>  
> 
> Modified: trunk/samples/ompi-core-template.ini
> ==
> --- trunk/samples/ompi-core-template.ini  (original)
> +++ trunk/samples/ompi-core-template.ini  2006-10-29 08:35:58 EST (Sun, 
> 29 Oct 2006)
> @@ -91,9 +91,15 @@
>  # returned by &env_max_procs(), you can fill in an integer here.
>  max_np = 
>  
> -# Output display preference
> +# OMPI Core: Output display preference; the default width at which MTT
> +# output will wrap.
>  textwrap = 76
>  
> +# OMPI Core: After the timeout for a command has passed, wait this
> +# many additional seconds to drain all output, and then kill it with
> +# extreme prejiduce.
> +

Re: [MTT users] Discussion on teleconf yesterday?

[Ethan Mallove]

Tues, Oct 31 at 1p is okay with everyone for an MTT
conference call. (Unless there are more IU people, besides
Josh and Tim M, I need to hear from.)

Objections?

Jeff, I think we're ready for the conference tel. #.

-Ethan



On Fri, Oct/27/2006 02:36:46PM, Tim Mattox wrote:
> On 10/27/06, Josh Hursey  wrote:
> >
> > On Oct 27, 2006, at 12:56 PM, Jeff Squyres wrote:
> > > Ethan -- can you coordinate with everyone to find a time that works?
> > > I can setup a phone bridge if necessary.  Monday all day and Tuesday
> > > afternoon work for me.
> >
> > Monday may not be possible for the IU group there is an all day thing
> > that many of us will be part of.
> >
> > Tuesday afternoon is open for me, the morning is filled with meetings.
> >
> > -- Josh
> 
> I am not available on Monday, nor Tuesday morning.
> Tuesday afternoon I should be available.  Wednesday works for me as well.
> -- 
> Tim Mattox - http://homepage.mac.com/tmattox/
>  tmat...@gmail.com || timat...@open-mpi.org
> I'm a bright... http://www.the-brights.net/
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

[MTT users] &join funclet and EvaluateString

[Ethan Mallove]

I need to compile a testsuite like this:

shell_build_command = &join("configure --with-lib-mpi=", &test_prefix(), 
"gmake")

But MTT errors out with:

Building Shell
Evaluating: &join("configure --with-lib-mpi=", &test_prefix(), "gmake")
Got name: test_prefix
Got args:
_do: $ret = MTT::Values::Functions::test_prefix()
&test_prefix returning: my_mpi/install/dir
String now: &join("configure --with-lib-mpi=", my_mpi/install/dir, "gmake")
Got name: join
Got args: "configure --with-lib-mpi=", my_mpi/install/dir, "gmake"
_do: $ret = MTT::Values::Functions::join("configure --with-lib-mpi=", 
my_mpi/install/dir, "gmake")
Bareword found where operator expected at (eval 33) line 1, near "/opt/mtt"
(Missing operator before tt?)
Bareword found where operator expected at (eval 33) line 1, near "1.3a1r12364"
(Missing operator before a1r12364?)
*** ERROR: Module aborted: MTT::Test::Build::Shell:Build: *** ERROR: Could not 
evaluate: $ret = MTT::Values::Functions::join("configure --with-lib-mpi=", 
my_mpi/install/dir, "gmake"): syntax error at (eval 33) line 1, near "/opt/mtt"

It looks like EvaluateString does not like the slashes,
because something silly like this doesn't give me the syntax
error:

shell_build_command = &join("configure --with-lib-mpi=", &test_np(), "gmake")

Note: Below is a patch to give Build.pm visibility of
test_prefix(), though this will also produce the error:

&join("configure --with-lib-mpi=", &shell("pwd"), "gmake")

-Ethan


Index: MTT/Test/Build.pm
===
--- MTT/Test/Build.pm   (revision 410)
+++ MTT/Test/Build.pm   (working copy)
@@ -251,6 +251,10 @@
 }
 }

+# Some test suites require knowledge of where
+# the MPI library is at the build stage
+$MTT::Test::Run::test_prefix = $mpi_install->{installdir};
+
 # Process setenv, unsetenv, prepend-path, and append-path -- for
 # both the MPI that we're building with and the section of the ini
 # file that we're building.

Re: [MTT users] &join funclet and EvaluateString

[Ethan Mallove]

Not sure if this is the best tack, but the below patch seems
to do the trick. What was happening was eval would barf when
it got the unquoted /foo/bar. Wrap the string in ""'s and
the error goes away. This snippet illustrates the problem:

$ perl -e 'eval "\"/foo/bar\"";'
$ perl -e 'eval "/foo/bar";'
Bareword found where operator expected at (eval 1) line 1,
near "/foo/bar"
(Missing operator before bar?)


Index: /workspace/em162155/hpc/mtt/schema2/trunk/lib/MTT/Values.pm
===
--- /workspace/em162155/hpc/mtt/schema2/trunk/lib/MTT/Values.pm (revision 410)
+++ /workspace/em162155/hpc/mtt/schema2/trunk/lib/MTT/Values.pm (working copy)
@@ -46,7 +46,7 @@
 # If we get a string back, just handle it.
 if (ref($ret) eq "") {
 # Substitute in the $ret in place of the &function(...)
-$str =~ s/(\&\w+\([^&\(]*?\))/$ret/;
+$str =~ s/(\&\w+\([^&\(]*?\))/"$ret"/;
 Debug("String now: $str\n");

 # Now loop around and see if there are any more
@@ -92,7 +92,14 @@
 return \@ret;
 }

-#Debug("No more functions left; final: $str\n");
+Debug("No more functions left; final: $str\n");
+return trim_quotes($str);
+}
+
+# Trim leading/trailing quotes
+sub trim_quotes {
+my ($str) = @_;
+$str =~ s/^\"+|\"+$//g;
 return $str;
 }

-Ethan


On Thu, Nov/02/2006 02:18:06PM, Ethan Mallove wrote:
> I need to compile a testsuite like this:
> 
> shell_build_command = &join("configure --with-lib-mpi=", &test_prefix(), 
> "gmake")
> 
> But MTT errors out with:
> 
> Building Shell
> Evaluating: &join("configure --with-lib-mpi=", &test_prefix(), "gmake")
> Got name: test_prefix
> Got args:
> _do: $ret = MTT::Values::Functions::test_prefix()
> &test_prefix returning: my_mpi/install/dir
> String now: &join("configure --with-lib-mpi=", my_mpi/install/dir, "gmake")
> Got name: join
> Got args: "configure --with-lib-mpi=", my_mpi/install/dir, "gmake"
> _do: $ret = MTT::Values::Functions::join("configure --with-lib-mpi=", 
> my_mpi/install/dir, "gmake")
> Bareword found where operator expected at (eval 33) line 1, near "/opt/mtt"
> (Missing operator before tt?)
> Bareword found where operator expected at (eval 33) line 1, near "1.3a1r12364"
> (Missing operator before a1r12364?)
> *** ERROR: Module aborted: MTT::Test::Build::Shell:Build: *** ERROR: Could 
> not evaluate: $ret = MTT::Values::Functions::join("configure 
> --with-lib-mpi=", my_mpi/install/dir, "gmake"): syntax error at (eval 33) 
> line 1, near "/opt/mtt"
> 
> It looks like EvaluateString does not like the slashes,
> because something silly like this doesn't give me the syntax
> error:
> 
> shell_build_command = &join("configure --with-lib-mpi=", &test_np(), "gmake")
> 
> Note: Below is a patch to give Build.pm visibility of
> test_prefix(), though this will also produce the error:
> 
> &join("configure --with-lib-mpi=", &shell("pwd"), "gmake")
> 
> -Ethan
> 
> 
> Index: MTT/Test/Build.pm
> ===
> --- MTT/Test/Build.pm (revision 410)
> +++ MTT/Test/Build.pm (working copy)
> @@ -251,6 +251,10 @@
>  }
>  }
>  
> +# Some test suites require knowledge of where
> +# the MPI library is at the build stage
> +$MTT::Test::Run::test_prefix = $mpi_install->{installdir};
> +
>  # Process setenv, unsetenv, prepend-path, and append-path -- for
>  # both the MPI that we're building with and the section of the ini
>  # file that we're building.
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

Re: [MTT users] &join funclet and EvaluateString

[Ethan Mallove]

On Thu, Nov/02/2006 03:24:48PM, Jeff Squyres wrote:
> On Nov 2, 2006, at 2:18 PM, Ethan Mallove wrote:
> 
> > I need to compile a testsuite like this:
> >
> > shell_build_command = &join("configure --with-lib-mpi=",  
> > &test_prefix(), "gmake")
> 
> I don't quite understand what the resulting command is supposed to do...
> 
> configure --with-lib-mpi=/foo/bar/baz gmake
> 
> ?
> 
> But if you really want that, can't you use:
> 
> shell_build_command = "configure --with-lib-mpi=&test_prefix() gmake"
> 

That doesn't work for me:

Building Shell
Evaluating: "configure --with-mpi-dir=&test_prefix() gmake"
Got name: test_prefix
Got args:
_do: $ret = MTT::Values::Functions::test_prefix()
&test_prefix returning:
my_mpi/install/dir
String now: "configure
--with-mpi-dir=my_mpi/install/dir
gmake"
No more functions left; final: "configure
--with-mpi-dir=my_mpi/install/dir
gmake"
Running command: /tmp/gaWTMDvUvr
OUT:configure: WARNING: you should use --build, --host,
--target
OUT:checking build system type... Invalid configuration
`gmake': machine `gmake' not recognized
OUT:configure: error: /bin/bash ./config.sub gmake failed
Command complete, exit status: 1
Writing built file:
/opt/mtt/netpipe/i386/32/trunk/installs/ompi-nightly-trunk/solaris_i386_32/1.3a1r12364/tests/imb_performance/PMB-2.2/test_built.ini
*** WARNING: Failed to build test [test build: imb
performance]: Shell: command failed "configure
--with-mpi-dir=my_mpi/install/dir
gmake"

-Ethan


> 
> 
> > But MTT errors out with:
> >
> > Building Shell
> > Evaluating: &join("configure --with-lib-mpi=", &test_prefix(),  
> > "gmake")
> > Got name: test_prefix
> > Got args:
> > _do: $ret = MTT::Values::Functions::test_prefix()
> > &test_prefix returning: my_mpi/install/dir
> > String now: &join("configure --with-lib-mpi=", my_mpi/install/dir,  
> > "gmake")
> > Got name: join
> > Got args: "configure --with-lib-mpi=", my_mpi/install/dir, "gmake"
> > _do: $ret = MTT::Values::Functions::join("configure --with-lib- 
> > mpi=", my_mpi/install/dir, "gmake")
> > Bareword found where operator expected at (eval 33) line 1, near "/ 
> > opt/mtt"
> > (Missing operator before tt?)
> > Bareword found where operator expected at (eval 33) line 1, near  
> > "1.3a1r12364"
> > (Missing operator before a1r12364?)
> > *** ERROR: Module aborted: MTT::Test::Build::Shell:Build: ***  
> > ERROR: Could not evaluate: $ret = MTT::Values::Functions::join 
> > ("configure --with-lib-mpi=", my_mpi/install/dir, "gmake"): syntax  
> > error at (eval 33) line 1, near "/opt/mtt"
> >
> > It looks like EvaluateString does not like the slashes,
> > because something silly like this doesn't give me the syntax
> > error:
> >
> > shell_build_command = &join("configure --with-lib-mpi=", &test_np 
> > (), "gmake")
> >
> > Note: Below is a patch to give Build.pm visibility of
> > test_prefix(), though this will also produce the error:
> >
> > &join("configure --with-lib-mpi=", &shell("pwd"), "gmake")
> >
> > -Ethan
> >
> >
> > Index: MTT/Test/Build.pm
> > ===
> > --- MTT/Test/Build.pm   (revision 410)
> > +++ MTT/Test/Build.pm   (working copy)
> > @@ -251,6 +251,10 @@
> >  }
> >  }
> >
> > +# Some test suites require knowledge of where
> > +# the MPI library is at the build stage
> > +$MTT::Test::Run::test_prefix = $mpi_install->{installdir};
> > +
> >  # Process setenv, unsetenv, prepend-path, and append-path -- for
> >  # both the MPI that we're building with and the section of the  
> > ini
> >  # file that we're building.
> > ___
> > mtt-users mailing list
> > mtt-us...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
> 
> 
> -- 
> 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

Re: [MTT users] &join funclet and EvaluateString

[Ethan Mallove]

On Thu, Nov/02/2006 05:47:14PM, Jeff Squyres wrote:
> I can't tell from the output -- it looks wrapped.
> 
> Did a \n get insertted in there somewhere?
> 
> More specifically, I don't see how the command is supposed to execute:
> 
> configure --with-lib-mpi=blah gmake
> 
> What exactly is that command supposed to do?  Don't you really want:
> 
> ./configure --with-lib-mpi=blah; gmake
> 

Right. I left out the ';'. It still errors out. It works
if I trim the leading/trailing quote(s).

String now: "configure --with-mpi-dir=foo/bar; gmake"
No more functions left; final: "configure --with-mpi-dir=foo/bar; gmake"
Running command: /tmp/VTzq0i9cqZ
OUT:/tmp/VTzq0i9cqZ[2]: configure --with-mpi-dir=foo/bar;
gmake:  not found
Command complete, exit status: 127
Writing built file:
/opt/mtt/netpipe/i386/32/trunk/installs/ompi-nightly-trunk/solaris_i386_32/1.3a1r12364/tests/imb_performance/PMB-2.2/test_built.ini
*** WARNING: Failed to build test [test build: imb
performance]: Shell: command failed ""configure
--with-mpi-dir=foo/bar;
gmake""

-Ethan


> ?
> 
> 
> On Nov 2, 2006, at 5:36 PM, Ethan Mallove wrote:
> 
> > On Thu, Nov/02/2006 03:24:48PM, Jeff Squyres wrote:
> >> On Nov 2, 2006, at 2:18 PM, Ethan Mallove wrote:
> >>
> >>> I need to compile a testsuite like this:
> >>>
> >>> shell_build_command = &join("configure --with-lib-mpi=",
> >>> &test_prefix(), "gmake")
> >>
> >> I don't quite understand what the resulting command is supposed to  
> >> do...
> >>
> >> configure --with-lib-mpi=/foo/bar/baz gmake
> >>
> >> ?
> >>
> >> But if you really want that, can't you use:
> >>
> >> shell_build_command = "configure --with-lib-mpi=&test_prefix() gmake"
> >>
> >
> > That doesn't work for me:
> >
> > Building Shell
> > Evaluating: "configure --with-mpi-dir=&test_prefix() gmake"
> > Got name: test_prefix
> > Got args:
> > _do: $ret = MTT::Values::Functions::test_prefix()
> > &test_prefix returning:
> > my_mpi/install/dir
> > String now: "configure
> > --with-mpi-dir=my_mpi/install/dir
> > gmake"
> > No more functions left; final: "configure
> > --with-mpi-dir=my_mpi/install/dir
> > gmake"
> > Running command: /tmp/gaWTMDvUvr
> > OUT:configure: WARNING: you should use --build, --host,
> > --target
> > OUT:checking build system type... Invalid configuration
> > `gmake': machine `gmake' not recognized
> > OUT:configure: error: /bin/bash ./config.sub gmake failed
> > Command complete, exit status: 1
> > Writing built file:
> > /opt/mtt/netpipe/i386/32/trunk/installs/ompi-nightly-trunk/ 
> > solaris_i386_32/1.3a1r12364/tests/imb_performance/PMB-2.2/ 
> > test_built.ini
> > *** WARNING: Failed to build test [test build: imb
> > performance]: Shell: command failed "configure
> > --with-mpi-dir=my_mpi/install/dir
> > gmake"
> >
> > -Ethan
> >
> >
> >>
> >>
> >>> But MTT errors out with:
> >>>
> >>> Building Shell
> >>> Evaluating: &join("configure --with-lib-mpi=", &test_prefix(),
> >>> "gmake")
> >>> Got name: test_prefix
> >>> Got args:
> >>> _do: $ret = MTT::Values::Functions::test_prefix()
> >>> &test_prefix returning: my_mpi/install/dir
> >>> String now: &join("configure --with-lib-mpi=", my_mpi/install/dir,
> >>> "gmake")
> >>> Got name: join
> >>> Got args: "configure --with-lib-mpi=", my_mpi/install/dir, "gmake"
> >>> _do: $ret = MTT::Values::Functions::join("configure --with-lib-
> >>> mpi=", my_mpi/install/dir, "gmake")
> >>> Bareword found where operator expected at (eval 33) line 1, near "/
> >>> opt/mtt"
> >>> (Missing operator before tt?)
> >>> Bareword found where operator expected at (eval 33) line 1, near
> >>> "1.3a1r12364"
> >>> (Missing operator before a1r12364?)
> >>> *** ERROR: Module aborted: MTT::Test::Build::Shell:Build: ***
> >>> ERROR: Could not evaluate: $ret = MTT::Values::Functions::join
> >>> ("configure --with-lib-mpi=", my_mpi/install/dir, "gmake"): syntax
> >>> error at (eval 33) line 1, near "/opt/mtt"
> 

Re: [MTT users] &join funclet and EvaluateString

[Ethan Mallove]

On Fri, Nov/03/2006 08:03:04AM, Jeff Squyres wrote:
> On Nov 2, 2006, at 6:11 PM, Ethan Mallove wrote:
> 
> >> ./configure --with-lib-mpi=blah; gmake
> >
> > Right. I left out the ';'. It still errors out. It works
> > if I trim the leading/trailing quote(s).
> 
> Right, sorry -- you don't need the quotes if you're not in functlet  
> args.  In this case, if you add quotes around the string, those will  
> be part of the field value (and in this case, since that field is  
> used to provide the value that is fork/exec'ed, you'll end up trying  
> to launch "foo" [which will fail] as opposed to foo [which would  
> success]).
> 
> For example, I use this in my ini file:
> 
> hostfile = /users/jsquyres/svn/mtt-core/&shell("hostname")/hostfile
> 
> So just to confirm -- this works:
> 
> command = ./configure --with-mpi-dir=&test_prefix(); gmake
> 
> Right?

Right. I still like doing trim_quotes before returning, so
that we're more forgiving in allowing ''both'' of these:

shell_build_command = configure --with-mpi-dir=&test_prefix(); gmake
shell_build_command = "configure --with-mpi-dir=&test_prefix(); gmake"

-Ethan

> 
> > String now: "configure --with-mpi-dir=foo/bar; gmake"
> > No more functions left; final: "configure --with-mpi-dir=foo/bar;  
> > gmake"
> > Running command: /tmp/VTzq0i9cqZ
> > OUT:/tmp/VTzq0i9cqZ[2]: configure --with-mpi-dir=foo/bar;
> > gmake:  not found
> > Command complete, exit status: 127
> > Writing built file:
> > /opt/mtt/netpipe/i386/32/trunk/installs/ompi-nightly-trunk/ 
> > solaris_i386_32/1.3a1r12364/tests/imb_performance/PMB-2.2/ 
> > test_built.ini
> > *** WARNING: Failed to build test [test build: imb
> > performance]: Shell: command failed ""configure
> > --with-mpi-dir=foo/bar;
> > gmake""
> >
> > -Ethan
> >
> >
> >> ?
> >>
> >>
> >> On Nov 2, 2006, at 5:36 PM, Ethan Mallove wrote:
> >>
> >>> On Thu, Nov/02/2006 03:24:48PM, Jeff Squyres wrote:
> >>>> On Nov 2, 2006, at 2:18 PM, Ethan Mallove wrote:
> >>>>
> >>>>> I need to compile a testsuite like this:
> >>>>>
> >>>>> shell_build_command = &join("configure --with-lib-mpi=",
> >>>>> &test_prefix(), "gmake")
> >>>>
> >>>> I don't quite understand what the resulting command is supposed to
> >>>> do...
> >>>>
> >>>> configure --with-lib-mpi=/foo/bar/baz gmake
> >>>>
> >>>> ?
> >>>>
> >>>> But if you really want that, can't you use:
> >>>>
> >>>> shell_build_command = "configure --with-lib-mpi=&test_prefix()  
> >>>> gmake"
> >>>>
> >>>
> >>> That doesn't work for me:
> >>>
> >>> Building Shell
> >>> Evaluating: "configure --with-mpi-dir=&test_prefix() gmake"
> >>> Got name: test_prefix
> >>> Got args:
> >>> _do: $ret = MTT::Values::Functions::test_prefix()
> >>> &test_prefix returning:
> >>> my_mpi/install/dir
> >>> String now: "configure
> >>> --with-mpi-dir=my_mpi/install/dir
> >>> gmake"
> >>> No more functions left; final: "configure
> >>> --with-mpi-dir=my_mpi/install/dir
> >>> gmake"
> >>> Running command: /tmp/gaWTMDvUvr
> >>> OUT:configure: WARNING: you should use --build, --host,
> >>> --target
> >>> OUT:checking build system type... Invalid configuration
> >>> `gmake': machine `gmake' not recognized
> >>> OUT:configure: error: /bin/bash ./config.sub gmake failed
> >>> Command complete, exit status: 1
> >>> Writing built file:
> >>> /opt/mtt/netpipe/i386/32/trunk/installs/ompi-nightly-trunk/
> >>> solaris_i386_32/1.3a1r12364/tests/imb_performance/PMB-2.2/
> >>> test_built.ini
> >>> *** WARNING: Failed to build test [test build: imb
> >>> performance]: Shell: command failed "configure
> >>> --with-mpi-dir=my_mpi/install/dir
> >>> gmake"
> >>>
> >>> -Ethan
> >>>
> >>>
> >>>>
> >>>>
> >>>>> But MTT errors out with:
> >>>>

Re: [MTT users] &join funclet and EvaluateString

[Ethan Mallove]

On Fri, Nov/03/2006 09:54:06AM, Jeff Squyres wrote:
> On Nov 3, 2006, at 9:46 AM, Ethan Mallove wrote:
> 
> >> So just to confirm -- this works:
> >>
> >> command = ./configure --with-mpi-dir=&test_prefix(); gmake
> >>
> >> Right?
> >
> > Right. I still like doing trim_quotes before returning, so
> > that we're more forgiving in allowing ''both'' of these:
> >
> > shell_build_command = configure --with-mpi-dir=&test_prefix(); gmake
> > shell_build_command = "configure --with-mpi-dir=&test_prefix(); gmake"
> 
> But what if there are cases where I *do* want quotes?
> 
> I'm more in favor of being as literal as possible.  What
> you type for  the shell_build_command will be directly
> launched.  This provides  greater flexiblity for if you
> *do* need quotes.  For example:
> 
> shell_build_command = ./configure "CFLAGS=-g -O"
> 
> In this case you definitely do not want to remove the quotes.
> 
> More specifically, proper quoting handling is a really,
> really tricky  task and I don't really want to tackle it.
> :-)
> 

Ah, sorry I was unclear. trim_quotes (not strip_quotes) will
remove only leading and trailing quotes. But right, it would
wreck something like this:

  shell_build_command = ./configure &my_cflags()

If you wanted the above to expand to:

  shell_build_command = ./configure "CFLAGS=-g -O"

My last proposal would be this:

---

Index: lib/MTT/DoCommand.pm
===
--- lib/MTT/DoCommand.pm(revision 411)
+++ lib/MTT/DoCommand.pm(working copy)
@@ -194,6 +194,11 @@
 select STDOUT;
 $| = 1;

+# Remove leading/trailing quotes, which
+# protects against a common funclet syntax error
+@$tokens[0] =~ s/^\"+//;
+@$tokens[(@$tokens - 1)] =~ s/\"+$//;
+
 # Run it!

 exec(@$tokens) ||
@@ -323,6 +328,11 @@
 $max_stdout_lines, $max_stderr_lines) = @_;

 my ($fh, $filename) = tempfile();
+
+# Remove leading/trailing quotes, which
+# protects against a common funclet syntax error
+$cmds =~ s/^\"+|\"+$//g;
+
 print $fh ":\n$cmds\n";
 close($fh);
 chmod(0700, $filename);

 

Point taken about being literal. My thinking is that most
will be only guessing about the quoting mechanism of
funclets (as I was for a bit), and there would never be a
real case for sending '"cmd"' to exec().

-Ethan

> -- 
> 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

Re: [MTT users] &join funclet and EvaluateString

[Ethan Mallove]

The patch was for DoCommand.pm which wouldn't affect @foo@,
right? (Isn't @foo@ dealt with in Run.pm?) I would revise
the patch to only chop the trailing '"' only if there is a
leading '"'. So we only remove quotes that wrap the whole
command.

+++ lib/MTT/DoCommand.pm(working copy)
+# Remove wrapping quotes, which
+# protects against a common funclet syntax error
+@$tokens[(@$tokens - 1)] =~ s/\"$//
+if ((@$tokens[0] =~ s/^\"//) > 0);
+

+
+# Remove wrapping quotes, which
+# protects against a common funclet syntax error
+$cmds =~ s/\"$//
+if (($cmds =~ s/^\"//) > 0);
+

I fold after this :)

-Ethan


On Fri, Nov/03/2006 01:21:03PM, Jeff Squyres wrote:
> On Nov 3, 2006, at 12:08 PM, Ethan Mallove wrote:
> 
> > Point taken about being literal. My thinking is that most
> > will be only guessing about the quoting mechanism of
> > funclets (as I was for a bit), and there would never be a
> > real case for sending '"cmd"' to exec().
> 
> How about a doc fix then?
> 
> I'm not so worried about a '"cmd"' to exec(), but more about other  
> fields.  Remember  that shell commands are a very small portion of  
> the fields used in MTT - there's others that are explicitly used as  
> portions of commands.  For example you could do something like this:
> 
> shell_command = ./configure @foo@
> foo = "CFLAGS=-g -O"
> 
> which then wouldn't work.
> 
> -- 
> 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

Re: [MTT users] &join funclet and EvaluateString

[Ethan Mallove]

On Fri, Nov/03/2006 03:31:40PM, Jeff Squyres wrote:
> No, @foo@ is evaluated when shell_command is evaluated. 

There's this block in Test/Run.pm, but I don't see the analogous
block anywhere else (e.g., Build or Install).

{{{
while ($exec =~ m/@(.+?)@/) {
my $val = $ini->val($mpi_details_section, $1);
if (!$val) {
Warning("Used undefined key @$1@ in exec value; skipping");
return;
}
$exec =~ s/@(.+?)@/$val/;
}
}}}


> So it would  have it's " chopped before it was folded into
> shell_command,  resulting in a the following:
>

> ./configure CFLAGS=-g -O
> 
> which would be wrong.
> 
> I admit to not having looked closely at your patch; would
> it handle  this scenario properly?
> 

No, the always erroneous command-wrapping quotes get chopped
just before they're passed to exec() in DoCommand. It would
not chop the trailing quote, because there's no leading
quote.

-Ethan


> 
> On Nov 3, 2006, at 1:21 PM, Jeff Squyres wrote:
> 
> > On Nov 3, 2006, at 12:08 PM, Ethan Mallove wrote:
> >
> >> Point taken about being literal. My thinking is that most
> >> will be only guessing about the quoting mechanism of
> >> funclets (as I was for a bit), and there would never be a
> >> real case for sending '"cmd"' to exec().
> >
> > How about a doc fix then?
> >
> > I'm not so worried about a '"cmd"' to exec(), but more about other
> > fields.  Remember  that shell commands are a very small portion of
> > the fields used in MTT - there's others that are explicitly used as
> > portions of commands.  For example you could do something like this:
> >
> > shell_command = ./configure @foo@
> > foo = "CFLAGS=-g -O"
> >
> > which then wouldn't work.
> >
> > -- 
> > 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
> 
> 
> -- 
> 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

Re: [MTT users] Valid INI file and MPI Details section

[Ethan Mallove]

I don't think MTT iterates over MPI Details sections the way
you expect. To run all the MPI Details sections, I think you
can factor down all those MPI Details sections to ''one''
using &enumerate():

exec = mpirun @hosts@ -mca 
  &enumerate("btl tcp,self", "btl
  mx,self", "btl mvapi,self") -np &test_np() --prefix
  &test_prefix() &test_executable() &test_argv() 

On Fri, Nov/03/2006 02:25:11PM, Josh Hursey wrote:
> I have an INI File that looks something like what is enclose at the  
> end of this message.
> 
> So I have multiple MPI Details sections. It seems like only the first  
> one is running. Do I have to list them out somewhere?
> 
> As a side question:
> Instead of using multiple MPI Details sections, if I use a single MPI  
> Details section and told MTT to iterate over the parameters to mpirun  
> at what point in the aggregation chain does this happen?
> Meaning will I see something like:
> 
> Building trunk
> Running trivial
> Runing mpirun -mca btl tcp,self
> Runing mpirun -mca btl mx,self
> Runing mpirun -mca btl mvapi,self
> Running intel
> Runing mpirun -mca btl tcp,self
> Runing mpirun -mca btl mx,self
> Runing mpirun -mca btl mvapi,self
> 
> or will I see
> 
> Building trunk
> Runing mpirun -mca btl tcp,self
> Running trivial
> Running intel
> Runing mpirun -mca btl mx,self
> Running trivial
> Running intel
> Runing mpirun -mca btl mvapi,self
> Running trivial
> Running intel
>
> 
> I would actually prefer the last because if something is broken with  
> the IB interconnect it doesn't slow down the other tests from  
> reporting. E.g. I can prioritize a bit in the INI file.

I do not think the last is possible at the moment, since
that would require iteration over a series of MPI Details
sections.

-Ethan


> 
> Cheers,
> Josh
> 
> mm
> #==
> # Overall configuration
> #==
> 
> [MTT]
> 
> hostfile =
> hostlist =
> max_np =
> 
> #--
> 
> #==
> # MPI get phase
> #==
> 
> [MPI get: ompi-nightly-trunk]
> mpi_details = Open MPI
> 
> module = OMPI_Snapshot
> ompi_snapshot_url = http://www.open-mpi.org/nightly/trunk
> 
> #--
> 
> #==
> # Install MPI phase
> #==
> 
> [MPI install: odin 32 bit gcc]
> mpi_get = ompi-nightly-trunk
> save_stdout_on_success = 1
> merge_stdout_stderr = 1
> vpath_mode = none
> 
> make_all_arguments = -j 6
> make_check = 1
> 
> compiler_name = gnu
> compiler_version = &shell("gcc --version | head -n 1 | awk '{ print \ 
> $3 }'")
> configure_arguments = \
> FCFLAGS=-m32 FFLAGS=-m32 CFLAGS=-m32 CXXFLAGS=-m32 \
> --with-wrapper-cflags=-m32 --with-wrapper-cxxflags=-m32 --with- 
> wrapper-fflags=-m32 --with-wrapper-fcflags=-m32
> 
> module = OMPI
> 
> #--
> 
> #==
> # MPI run details
> #==
> 
> [MPI Details: Open MPI tcp sm]
> exec = mpirun @hosts@ -mca btl tcp,sm,self -np &test_np() --prefix  
> &test_prefix() &test_executable() &test_argv()
> 
> # Yes, all these quotes are necessary.  Don't mess with them!
> hosts = &if(&have_hostfile(), "&join("--hostfile ", "&hostfile()")", \
>  "&if(&have_hostlist(), "&join("--host ", "&hostlist 
> ()")", "")")
> 
> after_each_exec = < if test "$MTT_TEST_HOSTFILE" != ""; then
>  args="--hostfile $MTT_TEST_HOSTFILE"
> elif test "$MTT_TEST_HOSTLIST" != ""; then
>  args="--host $MTT_TEST_HOSTLIST"
> fi
> orterun $args -np $MTT_TEST_NP --prefix $MTT_TEST_PREFIX  
> mtt_ompi_cleanup.pl
> EOT
> 
> #--
> 
> [MPI Details: Open MPI mx sm]
> exec = mpirun @hosts@ -mca btl mx,sm,self -np &test_np() --prefix  
> &test_prefix() &test_executable() &test_argv() 
> 
> # Yes, all these quotes are necessary.  Don't mess with them!
> hosts = &if(&have_hostfile(), "&join("--hostfile ", "&hostfile()")", \
>  "&if(&have_hostlist(), "&join("--host ", "&hostlist 
> ()")", "")")
> 
> after_each_exec = < if test "$MTT_TEST_HOSTFILE" != ""; then
>  args="--hostfile $MTT_TEST_HOSTFILE"
> elif test "$MTT_TEST_HOSTLIST" != ""; then
>  args="--host $MTT_TEST_HOSTLIST"
> fi
> orterun $args -np $MTT_TEST_NP --prefix $MTT_TEST_PREFIX  
> mtt_ompi_cleanup.pl
> EOT
> 
> #--
> 
> [MPI Details: Open MPI mvapi sm]
> exec = mpirun @hosts@ -m

Re: [MTT users] reporter weirdness

[Ethan Mallove]

On Mon, Nov/06/2006 09:08:32AM, Jeff Squyres wrote:
> This is odd:
> 

http://tinyurl.com/y4aetm

> 
> It shows "Fail / 2" for some of the tests, but I only see one  
> output.  What does that mean?
>

If you set "Date Aggregattion" to "Second-by-Second" it
shows I ran the same tests multiple times during the past 24
hrs (which happens because I'm using a fresh scratch tree
each time). (See http://tinyurl.com/y9fyly.)

E.g.,

2006-11-05 17:05:25 sun4u SunOS 5.10 ...v1.2 ..r12431 ..64-bit ibm sun 5.7 0 1
2006-11-05 21:39:18 sun4u SunOS 5.10 ...v1.2 ..r12431 ..64-bit ibm sun 5.7 0 1
2006-11-06 08:39:52 sun4u SunOS 5.10 ...v1.2 ..r12431 ..64-bit ibm sun 5.7 0 1

-Ethan


> 
> -- 
> Jeff Squyres
> Server Virtualization Business Unit
> Cisco Systems
> 

Re: [MTT users] reporter weirdness

[Ethan Mallove]

On Mon, Nov/06/2006 11:15:04AM, Jeff Squyres wrote:
> Still weird, though, that it shows 2 failures but then
> only 1 output.
> 
> We should fix that in the 2.0 reporter...
> 

The outputs ''are'' identical (see below), so GROUP BY is
doing its job. We could rethink how we use the aggregating
functions if you'd rather show seperate rows regardless of
whether stdout, stderr, env, etc. are identical.

-
Config args:
N/A

Stdout:
Configuring Open MPI/IBM test suite
checking for a BSD-compatible install...
/pkg/gnu/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... i386-pc-solaris2.10
checking host system type... i386-pc-solaris2.10
checking for gcc... mpicc
checking for C compiler default output file name...
configure: error: C compiler cannot create executables
See `config.log for more details.
make: *** No targets specified and no makefile found. Stop.

Stderr:
N/A

Env:
N/A

Test duration:
00:00:03
-

-Ethan


> 
> On Nov 6, 2006, at 10:31 AM, Ethan Mallove wrote:
> 
> > On Mon, Nov/06/2006 09:08:32AM, Jeff Squyres wrote:
> >> This is odd:
> >>
> >
> > http://tinyurl.com/y4aetm
> >
> >>
> >> It shows "Fail / 2" for some of the tests, but I only see one
> >> output.  What does that mean?
> >>
> >
> > If you set "Date Aggregattion" to "Second-by-Second" it
> > shows I ran the same tests multiple times during the past 24
> > hrs (which happens because I'm using a fresh scratch tree
> > each time). (See http://tinyurl.com/y9fyly.)
> >
> > E.g.,
> >
> > 2006-11-05 17:05:25 sun4u SunOS 5.10 ...v1.2 ..r12431 ..64-bit ibm  
> > sun 5.7 0 1
> > 2006-11-05 21:39:18 sun4u SunOS 5.10 ...v1.2 ..r12431 ..64-bit ibm  
> > sun 5.7 0 1
> > 2006-11-06 08:39:52 sun4u SunOS 5.10 ...v1.2 ..r12431 ..64-bit ibm  
> > sun 5.7 0 1
> >
> > -Ethan
> >
> >
> >>
> >> -- 
> >> 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
> 
> 
> -- 
> 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

[MTT users] This morning's (EST) MTT submissions

[Ethan Mallove]

FYI - for 10 minutes this morning (9:15-9:25 AM EST) the mtt
database was getting moved to another partition on the
server, so you may have lost some results.

-Ethan

Re: [MTT users] make distclean option?

[Ethan Mallove]

Here's a workaround that might work. Put something like this
your INI file:

[Test build: foo]
test_get = foo
module = Shell
shell_build_command = make

[Test build: foo clean]
test_get = foo
module = Shell
shell_build_command = make distclean

Then do:

$ client/mtt --no-section clean ...

In a subsequent mtt run, do:

$ client/mtt --section clean --force

Or similarly, put all your [build: clean] sections in a
seperate INI file, and after your initial "real" mtt run do
something like:

$ client/mtt clean.ini --force

-Ethan


On Mon, Nov/06/2006 01:15:24PM, Jeff Squyres wrote:
> The intent was to leave the source around so that you could go look  
> at things if there was a problem (especially during a build).
> 
> A probably completed "Trim" phase would have solved this. :-\ (e.g.,  
> keep_successful_mpi_builds = 0).  But Trim is unfortunately quite  
> complex to implement -- that's the only reason it hasn't been done yet.
> 
> As a short-term options, which would you prefer:
> 
> 1. a post_build option that will run after a success build/install
> 2. an option to simply whack the entire source tree after a  
> successful build/install
> 
> 
> On Nov 6, 2006, at 1:10 PM, Josh Hursey wrote:
> 
> > Is there a 'post_build' flag in the [MPI Install] section? I'd like
> > to be able to execute a script or 'make distclean' after a version of
> > a branch has been built and installed.
> >
> > The problem is that we are getting close to our quota on some of the
> > machines that we are using (every night we generate a directory about
> > 1.3 GB, and that quickly adds up). Since the 'source' directory is
> > not really useful (except for config.log) once the branch is
> > installed I'd like to shrink it a bit (or remove it all together).
> >
> > Is there any way to do this currently?
> >
> > Cheers,
> > Josh
> >
> > ___
> > mtt-users mailing list
> > mtt-us...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
> 
> 
> -- 
> 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

[MTT users] New MTT home page

[Ethan Mallove]

Folks,

The MTT home page has been updated to display a number of
quick links divided up by date range, organization, and
testing phase (MPI installation, test build, and test run).
The custom and summary reports are linked from there.

http://www.open-mpi.org/mtt/

-- 
-Ethan

[MTT users] 1.2b1r12528 results DELETE

[Ethan Mallove]

When trying to DELETE some Test Runs for
1.2b1r12528 - I accidentally whacked 3,500 Test
Runs. If you have the mttdatabase_debug files
somewhere I can put them back in the database. My
apologies.

-- 
-Ethan

Re: [MTT users] New MTT home page

[Ethan Mallove]

How's it now?

[P] Passes
[F] Failures
[*] Passes and Failures


On Fri, Nov/10/2006 01:01:37PM, Tim Mattox wrote:
> Hi Ethan,
> These look great!  Can you add one more column of choices with the
> heading "Failed Test Runs" which would be the same as "Test Runs",
> but without the entries that had zero failures.
> 
> If it wouldn't be too much trouble, could you also add a "Past 48
> Hours" section,
> but this is lower priority than adding a "Failed Test Runs" column.
> 
> Thanks!
> 
> On 11/10/06, Ethan Mallove  wrote:
> > Folks,
> >
> > The MTT home page has been updated to display a number of
> > quick links divided up by date range, organization, and
> > testing phase (MPI installation, test build, and test run).
> > The custom and summary reports are linked from there.
> >
> > http://www.open-mpi.org/mtt/
> >
> > --
> > -Ethan
> > ___
> > mtt-users mailing list
> > mtt-us...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
> >
> 
> 
> -- 
> Tim Mattox - http://homepage.mac.com/tmattox/
>  tmat...@gmail.com || timat...@open-mpi.org
> I'm a bright... http://www.the-brights.net/
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

-- 
-Ethan

Re: [MTT users] [MTT bugs] [MTT] #132: Print BIG WARNING in client if MTTDatabase fails to submit properly

[Ethan Mallove]

On Fri, Nov/10/2006 11:11:39PM, MTT wrote:
> #132: Print BIG WARNING in client if MTTDatabase fails to submit properly
> --+-
>   Reporter:  jsquyres |   Owner:  emallove
>   Type:  defect   |  Status:  new 
>   Priority:  blocker  |   Milestone:  v1.1
>  Component:  Client side  | Version:  trunk   
> Resolution:   |Keywords:  
> --+-
> Old description:
> 
> > Add some intelligence in submit.php so that it knows when an insert into
> > the database has failed.
> >
> > Somehow convey back to the client that one or more inserts has failed so
> > that the client can print out a '''BIG HAIRY WARNING''' that the results
> > did not get successfully insertted.  When this happens, automatically
> > drop a database debug file containing all the data (so that it isn't
> > lost) and include its filename in the '''BIG HAIRY WARNING.'''  This file
> > can then be analyzed later for a post mortem, etc.  Be sure that this
> > file is ''always'' dropped when there's a database insert error,
> > regardless of what the INI file setting is for dropping database debug
> > files.
> >
> > Bonus points will be awarded if submit.php can communicate back to the
> > client ''which'' results failed to submit, but that's not a huge deal
> > (we'll be able to do this better in 2.0).
> >
> > The '''BIG HAIRY WARNING''' should probably be output by the client both
> > when it happens and at the very end of the run so that if all you see in
> > the morning is the end of the MTT run on the screen, the warning is there
> > and the user don't have to search through the output just to know if
> > their data submitted properly or not.
> 
> New description:
> 
>  Add some intelligence in submit.php so that it knows when an insert into
>  the database has failed.
> 
>  Somehow convey back to the client that one or more inserts has failed so
>  that the client can print out a '''BIG HAIRY WARNING''' that the results
>  did not get successfully insertted.  When this happens, automatically drop
>  a database debug file containing all the data (so that it isn't lost) and
>  include its filename in the '''BIG HAIRY WARNING.'''  This file can then
>  be analyzed later for a post mortem, etc.  Be sure that this file is
>  ''always'' dropped when there's a database insert error, regardless of
>  what the INI file setting is for dropping database debug files.
> 
>  Bonus points will be awarded if submit.php can communicate back to the
>  client ''which'' results failed to submit, but that's not a huge deal
>  (we'll be able to do this better in 2.0).
> 
>  The '''BIG HAIRY WARNING''' should probably be output by the client both
>  when it happens and at the very end of the run so that if all you see in
>  the morning is the end of the MTT run on the screen, the warning is there
>  and the user don't have to search through the output just to know if their
>  data submitted properly or not.

I'm used grepping on the --debug output from client/mtt, which means e.g., I
will now see double the number of POSTGRES ERRORs. Isn't that confusing? At the
*end* of the mtt run, I'd much prefer to just say, e.g., "34 SQL errors
occured". If they want to see the actual SQL error messages from submit.php,
users can do:

$ client/mtt --debug ... | tee debug && grep -i POSTGRES debug

If submit.php?debug is used, the exact submission entry that caused the error(s)
can be traced.

> 
>  The should be done on the trunk and the release branch; the code will
>  likely be at least slightly different between the two, but quite similar.
> 
> -- 
> Ticket URL: 
> MTT 
> Issue tracking for the MPI Testing Tool.


-- 
-Ethan

Re: [MTT users] Corrupted MTT database or incorrucet query

[Ethan Mallove]

I can infer that you have an MPI Install section labeled
"odin 64 bit gcc". A few questions:

* What is the mpi_get for that section (or how does that
  parameter get filled in by your automated scripts)?  
* Do you start with a fresh scratch tree every run?
* Could you email me your scratch/installs/mpi_installs.xml
  files?

I checked on how widespread this issue is, and found that
18,700 out of 474,000 Test Run rows in the past month have a
mpi_version/command (v1.2-trunk) mismatch. Occuring in both
directions (version=1.2, command=trunk and vice versa).
They occur on these clusters:

 Cisco MPI development cluster
 IU Odin
 IU - Thor - TESTING

There *is* that race condition in which one mtt submitting
could overwrite another's index. Do you have "trunk" and
"1.2" runs submitting to the database at the same time?


On Sun, Nov/12/2006 06:04:17PM, Jeff Squyres (jsquyres) wrote:
> 
>I feel somewhat better now.  Ethan - can you fix?
> -Original Message-
>From:   Tim Mattox [[1]mailto:timat...@open-mpi.org]
>Sent:   Sunday, November 12, 2006 05:34 PM Eastern Standard Time
>To: General user list for the MPI Testing Tool
>Subject:[MTT users] Corrupted MTT database or incorrucet query
>Hello,
>I just noticed that the MTT summary page is presenting
>incorrect information for our recent runs at IU.  It is
>showing failures for the 1.2b1 that actaully came from
>the trunk!  See the first entry in this table:
>http://www.open-mpi.org/mtt/reporter.php?&maf_start_test_timestamp=200
>6-11-12%2019:12:02%20through%202006-11-12%2022:12:02&ft_platform_id=co
>ntains&tf_platform_id=IU&maf_phase=runs&maf_success=fail&by_atom=*by_t
>est_case&go=Table&maf_agg_timestamp=-&mef_mpi_name=All&mef_mpi_version
>=All&mef_os_name=All&mef_os_version=All&mef_platform_hardware=All&mef_
>platform_id=All&agg_platform_id=off&1-page=off&no_bookmarks&no_bookmar
>ks
>Click on the [i] in the upper right (the first entry)
>to get the popup window which shows the MPIRrun cmd as:
>mpirun -mca btl tcp,sm,self -np 6 --prefix
>/san/homedirs/mpiteam/mtt-runs/odin/20061112-Testing-NOCLN/parallel-bl
>ock-3/installs/ompi-nightly-trunk/odin_64_bit_gcc/1.3a1r12559/install
>dynamic/spawn Note the path has "1.3a1r12559" in the
>name... it's a run from the trunk, yet the table showed
>this as a 1.2b1 run.  There are several of these
>missattributed errors.  This would explain why Jeff saw
>some ddt errors on the 1.2 brach yesterday, but was
>unable to reproduce them.  They were from the trunk!
>--
>Tim Mattox - [2]http://homepage.mac.com/tmattox/
> tmat...@gmail.com || timat...@open-mpi.org
>I'm a bright... [3]http://www.the-brights.net/
>___
>mtt-users mailing list
>mtt-us...@open-mpi.org
>[4]http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
> 
> References
> 
>1. mailto:timat...@open-mpi.org
>2. http://homepage.mac.com/tmattox/
>3. http://www.the-brights.net/
>4. http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users


-- 
-Ethan

Re: [MTT users] Corrupted MTT database or incorrucet query

[Ethan Mallove]

On Mon, Nov/13/2006 10:56:06AM, Josh Hursey wrote:
> 
> On Nov 13, 2006, at 10:27 AM, Ethan Mallove wrote:
> 
> >I can infer that you have an MPI Install section labeled
> >"odin 64 bit gcc". A few questions:
> >
> >* What is the mpi_get for that section (or how does that
> >  parameter get filled in by your automated scripts)?
> 
> I attached the generated INI file for you to look at.


> 
> It is the same value for all parallel runs of GCC+64bit (same value  
> for all branches)
> 
> 
> >* Do you start with a fresh scratch tree every run?
> 
> Yep. Every run, and all of the parallel runs.
> 
> >* Could you email me your scratch/installs/mpi_installs.xml
> >  files?
> 

> 
>   
> 
>   append_path=""
>
> bindir="/san/homedirs/mpiteam/mtt-runs/odin/20061112-Nightly/parallel-block-1/installs/ompi-nightly-trunk/odin_64_bit_gcc/1.3a1r12559/install/bin"
>c_bindings="1"
>compiler_name="gnu"
>compiler_version="3.4.6"
>configure_arguments="FCFLAGS=-m64 FFLAGS=-m64 CFLAGS=-m64 
> CXXFLAGS=-m64 --with-wrapper-cflags=-m64 --with-wrapper-cxxflags=-m64 
> --with-wrapper-fflags=-m64 --with-wrapper-fcflags=-m64"
>cxx_bindings="1"
>f77_bindings="1"
>f90_bindings="1"
>full_section_name="mpi install: odin 64 bit gcc"
>
> installdir="/san/homedirs/mpiteam/mtt-runs/odin/20061112-Nightly/parallel-block-1/installs/ompi-nightly-trunk/odin_64_bit_gcc/1.3a1r12559/install"
>
> libdir="/san/homedirs/mpiteam/mtt-runs/odin/20061112-Nightly/parallel-block-1/installs/ompi-nightly-trunk/odin_64_bit_gcc/1.3a1r12559/install/lib"
>merge_stdout_stderr="1"
>mpi_details="Open MPI"
>mpi_get_full_section_name="mpi get: ompi-nightly-trunk"
>mpi_get_simple_section_name="ompi-nightly-trunk"
>mpi_version="1.3a1r12559"
>prepend_path=""
>result_message="Success"
>setenv=""
>success="1"
>test_status="installed"
>timestamp="1163316821"
>unsetenv=""
>vpath_mode="none" />
> 
>   
> 

> The attached mpi_installs.xml is from the trunk+gcc+64bit parallel  
> scratch directory.
> 
> >
> >I checked on how widespread this issue is, and found that
> >18,700 out of 474,000 Test Run rows in the past month have a
> >mpi_version/command (v1.2-trunk) mismatch. Occuring in both
> >directions (version=1.2, command=trunk and vice versa).
> >They occur on these clusters:
> >
> > Cisco MPI development cluster
> > IU Odin
> > IU - Thor - TESTING
> >
> 
> Interesting...
> 
> >There *is* that race condition in which one mtt submitting
> >could overwrite another's index. Do you have "trunk" and
> >"1.2" runs submitting to the database at the same time?
> 
> Yes we do. :(
> 
> The parallel blocks as we call them are separate scratch directories  
> in which MTT is running concurrently. Meaning that we have N parallel  
> block scratch directories each running one instance of MTT. So it is  
> possible (and highly likely) that when the reporter phase fires all  
> of the N parallel blocks are firing it about the same time.
>

Likely, because the mtt runs start at the same time? Or because you
do the [Reporter:IU database] section for trunk/v1.2 at the same time?

> Without knowing how the reporter is doing the inserts into the  
> database I don't think I can help much more than that on debugging.  
> When the reporter fires for the DB:
>  - Does it start a transaction for the connection, do the inserts,  
> then commit?
>  - Does it ship the inserts to the server then allow it to run them,  
> or does the client do all of the individual inserts?
>

lib/MTT/Reporter/MTTDatabase.pm HTTP POSTs the results to
server/php/submit/index.php.  index.php iterates over all of
the results and INSERTs them one at a time, but for each
result it checks to see if that MPI Install (hardware, os,
mpi_version, ...) is already in the database. If it is, it
reuses that existing row, otherwise it creates a new row
(and the problem is the SELECT/INSERT is not at

Re: [MTT users] Corrupted MTT database or incorrucet query

[Ethan Mallove]

Folks,

I've done a few things to address the mismatched
configuration/results that Tim originally reported. That is,
I cleaned out the corrupted records, removed a race
condition, and made mtt print out SQL errors. As I have not
had success reproducing the issue on my own, I would greatly
appreciate it if you could forward me (and/or the list) any
output from the client that you see which looks something
like this:

*** WARNING:

#
# 1 MTTDatabase server error
# The data that failed to submit is in *.txt
# See the above output for more info.
#


--
-Ethan

On Sun, Nov/12/2006 05:34:23PM, Tim Mattox wrote:
> Hello,
> I just noticed that the MTT summary page is presenting
> incorrect information for our recent runs at IU.  It is
> showing failures for the 1.2b1 that actaully came from the
> trunk!  See the first entry in this table:
> http://www.open-mpi.org/mtt/reporter.php?&maf_start_test_timestamp=2006-11-12%2019:12:02%20through%202006-11-12%2022:12:02&ft_platform_id=contains&tf_platform_id=IU&maf_phase=runs&maf_success=fail&by_atom=*by_test_case&go=Table&maf_agg_timestamp=-&mef_mpi_name=All&mef_mpi_version=All&mef_os_name=All&mef_os_version=All&mef_platform_hardware=All&mef_platform_id=All&agg_platform_id=off&1-page=off&no_bookmarks&no_bookmarks
> 
> Click on the [i] in the upper right (the first entry) to get the popup
> window which shows the MPIRrun cmd as:
> 
> mpirun -mca btl tcp,sm,self -np 6 --prefix
> /san/homedirs/mpiteam/mtt-runs/odin/20061112-Testing-NOCLN/parallel-block-3/installs/ompi-nightly-trunk/odin_64_bit_gcc/1.3a1r12559/install
> dynamic/spawn
> 
> Note the path has "1.3a1r12559" in the name... it's a run
> from the trunk, yet the table showed this as a 1.2b1 run.
> 
> There are several of these missattributed errors.
> 
> This would explain why Jeff saw some ddt errors on the 1.2
> brach yesterday, but was unable to reproduce them.  They
> were from the trunk!
> -- 
> Tim Mattox - http://homepage.mac.com/tmattox/
>  tmat...@gmail.com || timat...@open-mpi.org
> I'm a bright... http://www.the-brights.net/
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

-- 
-Ethan

Re: [MTT users] [MTT svn] svn:mtt-svn r461

[Ethan Mallove]

Sweet! I guess the only ''drawback'' is the meta-data is
only accessable to perl, but who cares. I bet this fix will
make #118 easier.

http://svn.open-mpi.org/trac/mtt/ticket/118
  "Slim down result submissions to the bare essentials"


On Thu, Nov/30/2006 07:55:14AM, jsquy...@osl.iu.edu wrote:
> Author: jsquyres
> Date: 2006-11-30 07:55:07 EST (Thu, 30 Nov 2006)
> New Revision: 461
> 
> Removed:
>trunk/lib/XML/
> Modified:
>trunk/lib/MTT/Files.pm
>trunk/lib/MTT/MPI.pm
>trunk/lib/MTT/Test.pm
>trunk/lib/MTT/Test/RunEngine.pm
> 
> Log:
> Fixes #144
> 
> This commit is a bunch of things to improve the meta data handling and
> storage in the MTT client:
> 
>  * Remove the use of XML::Simple and use Data::Dumper instead.  This
>allows us to remove the costly/slow (and error-prone when coding up
>new data layers) data transformation for each of the datasets that
>were saved out to disk.  The output data is about the same size,
>but we avoid the [potentially] huge memory transformation before
>the write, and for large data sets (e.g., Test run data), can save
>quite a bit of time (e.g., ~3 seconds with Data::Dumper vs. ~10
>seconds with XML::Simple).
>  * Split the Test run data up into multiple files instead of one huge
>file.  This allows us to write only the new data after tests have
>run rather than having to write ''all'' the data ''every'' time.
>It makes the reading and writing of the test run data a little more
>complex, but the performance win is worth it.
>  * Write the Test Run data [slightly] less frequently -- i.e., write
>out a [small] batch of new Test Run data periodically rather than
>writing after ''every'' test.
> 
> 
> Modified: trunk/lib/MTT/Files.pm
> ==
> --- trunk/lib/MTT/Files.pm(original)
> +++ trunk/lib/MTT/Files.pm2006-11-30 07:55:07 EST (Thu, 30 Nov 2006)
> @@ -40,8 +40,15 @@
>  
>  #--
>  
> -sub mkdir {
> +sub safe_mkdir {
>  my ($dir) = @_;
> +MTT::Files::mkdir($dir, 1);
> +}
> +
> +#--
> +
> +sub mkdir {
> +my ($dir, $safe) = @_;
>  
>  my $c = cwd();
>  Debug("Making dir: $dir (cwd: $c)\n");
> @@ -58,6 +65,9 @@
>  foreach my $p (@parts) {
>  next if (! $p);
>  
> +$p = make_safe_filename($p)
> +if ($safe);
> +
>  $str .= "$p";
>  if (! -d $str) {
>  Debug("$str does not exist -- creating\n");
> @@ -402,6 +412,8 @@
>  return 1;
>  }
>  
> +#--
> +
>  # Copy infile or stdin to a unique file in /tmp
>  sub copyfile {
>  
> @@ -432,4 +444,64 @@
>  return $outfile;
>  }
>  
> +#--
> +
> +sub load_dumpfile {
> +my ($filename, $data) = @_;
> +
> +# Check that the file is there
> +return
> +if (! -r $filename);
> +
> +# Get the file size
> +my ($dev, $ino, $mode, $nlink, $uid, $gid, $rdev, $size,
> +$atime, $mtime, $ctime, $blksize, $blocks) = stat($filename);
> +
> +# Read it in
> +open IN, $filename;
> +my $tmp;
> +read(IN, $tmp, $size);
> +close IN;
> +
> +# It's in Dumper format.  How many $VARx's are there?
> +return
> +if (! $tmp =~ m/\$VAR[0-9]+/g);
> +my $count = 0;
> +++$count
> +while ($tmp =~ m/\$VAR[0-9]+/g);
> +
> +# We know how many $VARx's there are.  Build up a string to eval.
> +my $str;
> +my $var_num = 1;
> +while ($var_num <= $count) {
> +$str .= "my \$VAR$var_num;\n";
> +++$var_num;
> +}
> +$str .= "eval \$tmp;\n";
> +my $var_num = 1;
> +while ($var_num <= $count) {
> +$str .= "\$\$data->{VAR$var_num} = \$VAR$var_num;\n";
> +++$var_num;
> +}
> +eval $str;
> +}
> +
> +#--
> +
> +sub save_dumpfile {
> +my ($filename) = @_;
> +shift;
> +
> +# Serialize
> +my $d = new Data::Dumper([@_]);
> +$d->Purity(1)->Indent(1);
> +
> +open FILE, ">$filename.new";
> +print FILE $d->Dump;
> +close FILE;
> +
> +# Atomically move it onto the old file
> +rename("$filename.new", $filename);
> +}
> +
>  1;
> 
> Modified: trunk/lib/MTT/MPI.pm
> ==
> --- trunk/lib/MTT/MPI.pm  (original)
> +++ trunk/lib/MTT/MPI.pm  2006-11-30 07:55:07 EST (Thu, 30 Nov 2006)
> @@ -15,10 +15,9 @@
>  package MTT::MPI;
>  
>  use strict;
> -use XML::Simple qw(:strict);
>  use MTT::MPI::Get;
>  use MTT::MPI::Install;
> -use Data::Dumper;
> +use MTT::Files;
>  
>  #--

[MTT users] MTT 2.0 Rollout

[Ethan Mallove]

Folks,

MTT 2.0 will be ready for you to try shortly after New
Year's Day. Some improvements in MTT 2.0 are:

  * Improved web interface to reports
  * Performance graphs for IMB and NetPipe suites
  * More efficient database design

Let me know when you will have time in January to try some
runs with the new MTT.

-Ethan

[MTT users] MTT 2.0 Rollout

[Ethan Mallove]

Hello,

Below is a link to a wiki page containing:

 1. What's new in MTT 2.0
 2. Schedule for the MTT 2.0 rollout
 3. MTT 1.0 to MTT 2.0 Transition Steps

https://svn.open-mpi.org/trac/mtt/wiki/News-03-Jan-2007

Our goal is to have everyone moved over to MTT 2.0 by
January 19. Hopefully this will be a painless process, but
do keep the list apprised of any aches or discomfort.

Thanks!

-Ethan

[MTT users] "Cherry picking" feature

[Ethan Mallove]

Folks,

I forgot to mention on Tuesday's teleconference, a useful
feature in Performance mode. If you click Performance, above
the graphs is a summary with a far left column containing
checkboxes. Those checkboxes allow you to ''cherry pick''
which rows to plot in the below graphs. So you can
check/uncheck them and then click the ''cherry'' button at
the foot of the table to prune out line plots. Test it out
here:

http://www.open-mpi.org/~emallove/mtt/reporter.php?do_redir=62

-Ethan

Re: [MTT users] reserved key words ?

[Ethan Mallove]

So you must have MPI install sections that look a little
like:

[MPI install: foo debug non-threaded]
[MPI install: foo debug threaded]
[MPI install: foo release non-threaded]
[MPI install: foo release threaded]

?

Don't you want to search on ''configure arguments''?  That
can be done right now, but only in the ''MPI install'' view?
Would it help to have that searchable in ''all'' views?

-Ethan


On Fri, Jan/12/2007 03:06:52PM, Sven Stork wrote:
> Dear all,
> 
> I configure one of our test system to build and run all 4
> combinations of debug/release and threaded/non-threaded. I
> put the corresponding words into the different MPI section
> titles.
> 
> So far the only way I found to search for these "tags" is
> via the command field (because the section title is
> available as part of the prefix parameter).
> 
> Is there a simpler way to search for such "tags" ?
> 
> Wouldn't it make sense to agree on some "official tags ? 
> 
> Thanks,
>  Sven 
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

[MTT users] MCA parameters reporting

[Ethan Mallove]

Folks,

One of the questions that came up during the teleconference
last Tuesday was, "how can we use reporter.php to display
e.g., the performance of different BTLs"?  At the time there
was little to cover that use case, but now there's
something.

If you type a regular expression into the Command text
field, the first pattern that matches the expression is
captured and will show up in the Summary table.  Thus, you
can type e.g., "tcp|openib" into the Command field and there
will be a Command column differentiating the rows by
displaying the occurrence of the pattern "tcp" and "openib"
in the mpirun command.

Go here for an example:
http://www.open-mpi.org/~emallove/mtt/reporter.php?do_redir=65

Note: In addition to the Command field, all *large* fields
have this behavior, and can be identified in reporter.php as
*not* having an adjacent Show/Hide menu. (They are "Stdout",
"Stderr", "Environment", "Result message", "Configure
arguments", and "Command"). Here's another example with a
"Configure arguments" filter:

http://www.open-mpi.org/~emallove/mtt/reporter.php?do_redir=66

-Ethan

[MTT users] MTT 2.0 switchover status

[Ethan Mallove]

We are a little behind schedule in getting ''everyone''
switched over to the MTT trunk, so we are pushing the date
for switching back to the ompi-core-testers branch to
Monday, January 22.

https://svn.open-mpi.org/trac/mtt/wiki/News-03-Jan-2007#SchedulefortheMTT2.0rollout

-Ethan

Re: [MTT users] Minor bug found in MTT 2 client side.

[Ethan Mallove]

On Fri, Jan/19/2007 08:55:26AM, Tim Mattox wrote:
> Hi All,
> 
> On 1/18/07, Jeff Squyres  wrote:
> > On Jan 18, 2007, at 10:37 PM, Tim Mattox wrote:
> [snip description of a newline bug]
> 
> > Fixed -- none have newlines now, so they'll all be in the one-line
> > output format.
> 
> Thanks.
> 
> > > I don't know if it is related or not, but for tests that fail without
> > > timing out,
> > > the debug output from MTT for that test does NOT have a line like
> > > these:
> > > test_result: 1  (passed)
> > > test_result: 2  (skipped)
> > > test_result: 3  (timed out)
> >
> > Are you sure?  Lines 80-84 of Correctness.pm are:
> >
> >  if ($results->{timed_out}) {
> >  Warning("$str TIMED OUT (failed)\n");
> >  } else {
> >  Warning("$str FAILED\n");
> >  }
> >
> > Are you talking about some other output?  Or are you asking for
> > something in (parentheses)?
> 
> Sorry, I wasn't clear.  The current output for each test in the debug file
> usually includes a line "test_result: X" with X replaced by a number.
> However, for tests that fail outright, this line is missing.  This missing
> line happened to correspond to the tests that had a newline in the result
> message that I discussed (snipped) above.
> 
> Please don't put in the parentheses things.  That was just me commenting
> on which number meant what.
> 
> 
> > If you're in the middle of revamping your parser to match the MTT 2.0
> > output, I might suggest that it might be far easier to just
> > incorporate your desired output into MTT itself, for two reasons:
> >
> > 1. the debug output can change at any time; it was meant to be for
> > debugging, not necessarily for screen scraping.
> 
> Point taken.
> 
> > 2. there would be no need for screen scraping/parsing; you would have
> > the data immediately available and all you have to do is output it
> > into the format that you want.  We should be able to accommodate
> > whatever you need via an MTT Reporter plugin.  I'm guessing this
> > should be pretty straightforward...?
> 
> Where can I find some documentation for or examples of a plugin?

They're all in this directory:

https://svn.open-mpi.org/trac/mtt/browser/trunk/lib/MTT/Reporter/

You probably want to look at these:

https://svn.open-mpi.org/trac/mtt/browser/trunk/lib/MTT/Reporter/TextFile.pm
https://svn.open-mpi.org/trac/mtt/browser/trunk/lib/MTT/Reporter/Email.pm
https://svn.open-mpi.org/trac/mtt/browser/trunk/lib/MTT/Reporter/INIFile.pm

-Ethan

> 
> > --
> > Jeff Squyres
> > Server Virtualization Business Unit
> > Cisco Systems
> 
> 
> -- 
> Tim Mattox - http://homepage.mac.com/tmattox/
>  tmat...@gmail.com || timat...@open-mpi.org
> I'm a bright... http://www.the-brights.net/
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

Re: [MTT users] Minor bug found in MTT 2 client side.

[Ethan Mallove]

Tim,

I wonder if reporter.php can help out some here. IIRC, a
major advantage of your parsing scripts was to see results
of individual MTT invocations, and characteristics of
invocations that reporter.php wasn't able to show.
reporter.php now keeps track of results ''by invocation''
much more systematically then before.  Could you give me a
use case of what you want you want in a report? (Or point me
to some examples in ompi-tests/trunk/iu/mtt - Josh had some
mock ups of your reports, but I lost track of them.)

-Ethan


On Fri, Jan/19/2007 11:50:54AM, Jeff Squyres wrote:
> On Jan 19, 2007, at 8:55 AM, Tim Mattox wrote:
> 
> > Sorry, I wasn't clear.  The current output for each test
> > in the  debug file usually includes a line "test_result:
> > X" with X replaced by a number.  However, for tests that
> > fail outright, this line is missing.  This  missing line
> > happened to correspond to the tests that had a newline
> > in the  result message that I discussed (snipped) above.
> >
> > Please don't put in the parentheses things.  That was just me  
> > commenting
> > on which number meant what.
> 
> I forgot to mention -- let me know where you land on the whole  
> "continue to parse debug output" vs. "write an MTT reporter" issue.   
> If you write a new reporter, this particular issue ^^ is moot.
> 
> -- 
> 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

Re: [MTT users] Minor bug found in MTT 2 client side.

[Ethan Mallove]

Just remembered where I put the examples Josh sent me :)

Here are some attempts at getting reporter.php to do similar
things to your custom report(s).

Summary page:

http://www.open-mpi.org/~emallove/mtt/reporter.php?do_redir=74

Display test name, np, and duration (for ''intel'' tests
only):

http://www.open-mpi.org/~emallove/mtt/reporter.php?do_redir=75

Clicking the down arrow to the right of the duration header
sorts the results, ''longest'' running time first:

http://www.open-mpi.org/~emallove/mtt/reporter.php?do_redir=76

Next, it looks like you want to split out 32/64-bit results.
Do they have identifiable configure arguments? Sun has two
sets of configure arguments ('-xarch=v8' for 32 and
'-xarch=v9' for 64), which can be reported on like so:

http://www.open-mpi.org/~emallove/mtt/reporter.php?do_redir=66

-Ethan


On Fri, Jan/19/2007 01:57:16PM, Ethan Mallove wrote:
> Tim,
> 
> I wonder if reporter.php can help out some here. IIRC, a
> major advantage of your parsing scripts was to see results
> of individual MTT invocations, and characteristics of
> invocations that reporter.php wasn't able to show.
> reporter.php now keeps track of results ''by invocation''
> much more systematically then before.  Could you give me a
> use case of what you want you want in a report? (Or point me
> to some examples in ompi-tests/trunk/iu/mtt - Josh had some
> mock ups of your reports, but I lost track of them.)
> 
> -Ethan
> 
> 
> On Fri, Jan/19/2007 11:50:54AM, Jeff Squyres wrote:
> > On Jan 19, 2007, at 8:55 AM, Tim Mattox wrote:
> > 
> > > Sorry, I wasn't clear.  The current output for each test
> > > in the  debug file usually includes a line "test_result:
> > > X" with X replaced by a number.  However, for tests that
> > > fail outright, this line is missing.  This  missing line
> > > happened to correspond to the tests that had a newline
> > > in the  result message that I discussed (snipped) above.
> > >
> > > Please don't put in the parentheses things.  That was just me  
> > > commenting
> > > on which number meant what.
> > 
> > I forgot to mention -- let me know where you land on the whole  
> > "continue to parse debug output" vs. "write an MTT reporter" issue.   
> > If you write a new reporter, this particular issue ^^ is moot.
> > 
> > -- 
> > 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
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
From: MPI Team 
List-Post: mtt-users@lists.open-mpi.org
Date: October 24, 2006 9:21:10 AM EDT
To: mini-lla...@lam-mpi.org, jjhur...@open-mpi.org
Subject: MTT - Odin 8 Processor Nightly - 32 and 64 bit gcc


  Run Title   
mm
 Odin 8 Processor Nightly - 32 and 64 bit gcc

 Access MTT Results via web iterface:
 ( You need the username/password: ompi/mtt to access these sites )
  http://www.open-mpi.org/mtt/
  https://www.open-mpi.org/mtt/summary.php


  Date   
mm
Stamped: 10-24-2006-02-30-02
Start Date : Tue Oct 24 02:30:02 EDT 2006
End   Date : Tue Oct 24 09:21:10 EDT 2006
   Total elapsed: 06:11:55



 Results 
mm
Nightly All Test Totals
mm
Total # of tests Ran:  2596
Total # of tests Passed :  2533
Total # of tests Failed :63

Branch Results for ompi-nightly-trunk (1.3a1r12274)
mm
Total # of branch tests Ran:  1298
Total # of branch tests Passed :  1264
Total # of branch tests Failed :34

Branch Results for ompi-nightly-v1.2 (1.2a1r12263)
mm
Total # of branch tests Ran:  1298
Total # of branch tests Passed :  1269
Total # of branch tests Failed :29

--
ompi-nightly-trunk   ( 1.3a1r12274) - odin 32 bit gcc warnings
   Build Time:  531 seconds [00:08:51]
   Total: 649   Pass:  632  Fail:  17   
--
--
TEST SUITE:ibm
   Run Time:364 sec [00:06:04]  Longest Time to Pass (11 
seconds)
   Total: 181   Pass:  178  Fail:  3

Re: [MTT users] [devel-core] first steps with MTT

[Ethan Mallove]

Hi Andreas,

mtt-us...@open-mpi.org is where you want to send MTT-related
stuff.

On Tue, Jan/23/2007 09:12:59AM, Andreas Kn?pfer wrote:
> Hello everyone,
> 
> After our first experiments with MTT I'd like to ask a
> couple of questions. I guess, if I put them here the
> answers will go to the list archive as well.  maybe I can
> write a wiki page for the first steps towards MTT, too.
> 
> This leads me to the first question? what's the
> login/passwd for the wiki?  And how about the central data
> base for results? probably that answers should not go to
> the list.
>

There's anonymous read-only access to the wiki.

https://svn.open-mpi.org/trac/mtt/wiki

You need an HTTP account for sending up results to the
database. username's are organization names (e.g., cisco,
sun, lanl, etc.). What do you want as your username?
"tu-dresden" or "zih"?

> So far I'm using text output only. How can I set up an own
> data base? There are some PHP files in the MTT tarball. Do
> they initialize data base and tables and so on? is there
> any script for this? Does is require mysql or postgres or
> any of the two?
>

Postgres, but the server-side is already taken care of.
There's a centralized database setup at Indiana Univ, and
the MTT test results can be viewed here:
http://www.open-mpi.org/mtt.


> When I did my own test scripts for a simple test
> application I followed the example INI files provided and
> some pieces of documentation and the Perl code. Is there a
> "real" documentation about all bells and whistles? If not,
> could we write one or at least provide a step-by-step
> guide for beginners?

The wiki is a good starting point. There's links to a bunch
of stuff on the MTT home wiki page here: 

https://svn.open-mpi.org/trac/mtt/wiki

The closest thing to a Beginner's Guide to using the MTT
client would be:

https://svn.open-mpi.org/trac/mtt/wiki/MTTOverview

> 
> When I want to do some tests whether a test run was
> successful of not, which way would you suggest. Either
> doing it in bash commands placed in the INI file or rather
> write new Perl modules that will be specific to my
> application? The trivial test case does part of both,
> doesn't it?
>

B. new Perl modules :)

But the test suites that are listed in the
samples/ompi-core-templates.ini file already have modules in
place to Get (e.g., svn export), Build (e.g., make), Run
(mpirun), and Analyze (prepare test results for the
database).

If you add a *new* test suite to ompi-tests, the existing
modules should be able to do all of the above (with the
exception of Analyze, if the test outputs performance data).
You just might need to add some special conditions in the [Test
run: foo] section of the INI file to indicate e.g., whether
some tests are *supposed* to fail, some tests take longer
time span to run, etc.


> Furthermore, there is a caching scheme for test results
> between successive runs. MTT avoids test that were run
> before. Where does it store this information? How to
> explicitly clear it?
> 

The cached data is stored as serialized Perl variables
down in the scratch directory.

The --force option "forces" MTT to run everything,
regardless of whether it's been run before.

> 
> As one of our current goals, I'm integrating VampirTrace
> into the MTT test cycle. The most straight forward way
> would be to have a test application tarball which includes
> VampirTrace sources, wouldn't it? Would it be feasible to
> have two download clauses in a single test-get phase and
> two successive build clauses in a single test-build
> phase? Could this work with the current macros?
>

I don't know of a user that's done two fetches/compiles in a
single section yet. Why do you need to download/build twice
for a single test suite?  (There's nothing preventing this,
just wondering.) I think what you want would look something
like this:

[Test get: VampirTrace]
url1 = http://www.foo.com
url2 = http://www.bar.com
module = Tarball

[Test build: VampirTrace]
module = Shell
shell_build_command = < 
> Thank you very much for your answers! 
> Andreas
> 
> -- 
> Dipl. Math. Andreas Knuepfer, 
> Center for Information Services and 
> High Performance Computing (ZIH), TU Dresden, 
> Willersbau A114, Zellescher Weg 12, 01062 Dresden
> phone +49-351-463-38323, fax +49-351-463-37773
> ___
> devel-core mailing list
> devel-c...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel-core

[MTT users] Deadline to go back to "testers" branch

[Ethan Mallove]

Folks,

The new branch has been cut. Please switch back to the
ompi-core-testers branch by Friday.  The SVN URL is
https://svn.open-mpi.org/svn/mtt/branches/ompi-core-testers.
The MTT 2.0 server-side scripts are located (again) at
http://www.open-mpi.org/mtt, which means you need to update
the mttdatabase_url parameter in your INI to be
http://www.open-mpi.org/mtt/submit/. (Careful, that trailing
'/' is needed!) Lastly, the Reporter is here
http://www.open-mpi.org/mtt/reporter.php.

Thanks!
Ethan

[MTT users] MTT proxy (for offline clusters)

[Ethan Mallove]

Folks,

If you have a cluster which can not access the Internet (and
thus can not submit results to www.open-mpi.org), there's a
solution now.  In mtt/trunk/client there's a simple web
proxy you can run like this:

$ client/mtt-relay --port 6789 &

Set mttdatabase_url as below in your [Reporter: IU database]
section, and your results should get submitted. 

mttdatabase_url = host.where.mtt-relay.runs:6789

-Ethan

[MTT users] MTT database performance boost

[Ethan Mallove]

Folks,

If some of you hadn't already noticed, reports (see
http://www.open-mpi.org/mtt/) on Test Runs have been taking
an upwards of 5-7 minutes to load as of late.  This was due
in part to some database design issues (compounded by the
fact that we now have nearly 3 million test results
archived, dating back to November).  To mitigate the
performance issues, there is now a sliding window n-day
"speedy" database that will be used automatically for recent
reports.  (Currently n=7, but there is only 2 days worth of
"speedy" data as of this email).  Reports which date back
earlier than the sliding window will take some time as they
will be coming from the slower "archive" database.

Cheers,
Ethan

Re: [MTT users] script to resubmit results

[Ethan Mallove]

I just added a client/mtt-submit script to the mtt/trunk SVN
repository which will help you.  You'll need to use it like
this:

$ client/mtt-submit -f '/directory/where/results/are/*.txt' -g -u cisco -p 


/directory/where/results/are/ is specified in your INI file
as mttdatabase_debug_filename.

CAUTION: Use this script with care!  For example, you could
end up with duplicate test results in the database if you
used mtt-submit twice on the same file.

-Ethan


On Thu, Mar/01/2007 08:40:17AM, Bill D'amico wrote:
> 
>We had a proxy server fail during the night and may have had some
>results get lost. Jeff asked me to check for existence of a
>resubmission script - is there one, and if so where is it?
> 
>--
>Bill D'Amico
>[1]bdam...@cisco.com
>Server virtualization Business Unit
> 
> References
> 
>1. mailto:bdam...@cisco.com

> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

Re: [MTT users] script to resubmit results

[Ethan Mallove]

Good point.  If the mtt client couldn't contact the
database, then Test Builds and Test Runs will not contain
their required mpi_install and test_build ID's (you'll see
FOREIGN KEY constraint errors in the output).

Not being able to contact the database is an Abort condition
at startup, but we need to sit in a waiting loop if we can't
get these prior phase ID's, right?

OR to avoid the waiting loop *and* make it robust, we could
point to a filename containing the data of a prior phase
submission in the absence of database connectivity.  Then we
would need to add logic to mtt-submit so that we re-submit
prior phases in cases of missing prior phase ID's.


On Thu, Mar/01/2007 01:20:53PM, Jeff Squyres wrote:
> Ethan -
> 
> Will this work to submit results for phases that don't have  
> corresponding prior phase IDs?
> 
> I.e., if I did an MPI install, Test build, and Test run phases -- and  
> none of them were successfully submitted -- will submitted the test  
> build/run data work, since they don't have a corresponding ID for the  
> MPI install phase?
> 
> 
> On Mar 1, 2007, at 12:40 PM, Ethan Mallove wrote:
> 
> > I just added a client/mtt-submit script to the mtt/trunk SVN
> > repository which will help you.  You'll need to use it like
> > this:
> >
> > $ client/mtt-submit -f '/directory/where/results/are/*.txt' -g -u  
> > cisco -p 
> >
> > /directory/where/results/are/ is specified in your INI file
> > as mttdatabase_debug_filename.
> >
> > CAUTION: Use this script with care!  For example, you could
> > end up with duplicate test results in the database if you
> > used mtt-submit twice on the same file.
> >
> > -Ethan
> >
> >
> > On Thu, Mar/01/2007 08:40:17AM, Bill D'amico wrote:
> >>
> >>We had a proxy server fail during the night and may have had some
> >>results get lost. Jeff asked me to check for existence of a
> >>resubmission script - is there one, and if so where is it?
> >>
> >>--
> >>Bill D'Amico
> >>[1]bdam...@cisco.com
> >>Server virtualization Business Unit
> >>
> >> References
> >>
> >>1. mailto:bdam...@cisco.com
> >
> >> ___
> >> mtt-users mailing list
> >> mtt-us...@open-mpi.org
> >> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
> >
> > ___
> > mtt-users mailing list
> > mtt-us...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
> 
> 
> -- 
> 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

Re: [MTT users] [Important] milliways downtime

[Ethan Mallove]

Folks,

When milliways is down, no MTT results can be submitted.  So
watch out for some of your MTT results going into the ether
at the below times.

milliways migration:

  date : Mar 9, Friday
  time : 7:00AM to 9:00AM ET

Possible second try on milliways migration:

  date : Mar 19
  time : 8:00AM to 5:00PM ET

-Ethan


- Forwarded message from DongInn Kim  -

From: DongInn Kim 
List-Post: mtt-users@lists.open-mpi.org
Date: Wed, 07 Mar 2007 13:45:58 -0500
To: "Shei, Shing-Shong" 
Cc: Internal OSL staff mailing list ,
    Ethan Mallove ,
Jeff Squyres ,
Rob Henderson 
Subject: Re: [Important] milliways downtime
OpenPGP: id=BE966DE5
Original-recipient: rfc822;ethan.mall...@sun.com

Hi Bruce,

Yes, I think it would be fine to do the migration this Friday early
morning(7:00AM to 9:00AM ?) if it won't take a long time when thing goes
well. I have asked several OSL people personally and I could not hear
any big objections about the new schedule.

So, the new migration date and time would be
1) date : Mar 9, Friday
2) time : 7:00AM to 9:00AM ET

If this migration does not work well, as you mentioned, we can roll back
to the original current milliways and then we still can do the migration
again with a plenty of time (8:00AM to 5:00PM ET) on Mar 19, Mon.

How does it sound?
Please let me know if you have any problems or concerns about the new
schedule.
I am sorry for the quick and changing schedules.

Regards,

- DongInn



Shei, Shing-Shong wrote:
> Hi,
>
> I hope that this is not a short notice -- we plan to reboot all our
> servers
> Friday (Mar 9th) morning (maybe between 7:00 and 8:00 AM) for two
> reasons:
> for the new kernel to kick in and make sure that DST change is in
> place.  I
> wonder if it's a good idea to take the chance to do the hardware
> swapping.
> If we do it this time and IF we are lucky, then we don't need to shutdown
> the machine again later as DongInn proposed.  I expect the downtime
> should
> not be longer than two hours if things go smoothly.  If it does not, then
> we still have the option to use the 'current' milliways as it is now and
> schedule another downtime as DongInn proposed.  Let me know.
>
> Thanks,
> Bruce
>> Hi,
>>
>> I think nobody really cares about the migration date except for someone
>> who I asked personally.
>>
>> The date that I would like to choose would be the third option: Someday
>> after Spring breaks, probably Monday Mar 19,2007.
>>
>> Please let me know if you have any issues or concerns of my choice.
>> If I do not hear any big objection about the date until tomorrow(3/8)
>> noon, I will announce the downtime to the all-osl-users mailing list
>> then.
>>
>> Regards,
>>
>> - DongInn
>>
>>   

- End forwarded message -

[MTT users] MTT server error (user: ibm)

[Ethan Mallove]

Camille,

Your results today were borked somehow.  What options did
you give to client/mtt?  *Something* happened with the
--trial option.  I patched the MTT client, though I've never
seen this error before.  Unfortunately, you would need to
re-run your tests (after doing "svn up") to submit them to
the DB :(

-Ethan


- Forwarded message from ethan.mall...@sun.com -

From: ethan.mall...@sun.com
List-Post: mtt-users@lists.open-mpi.org
Date: Fri, 09 Mar 2007 12:31:25 -0500
To: ethan.mall...@sun.com
Subject: MTT server error (user: ibm)
Sender: apa...@osl.iu.edu
Reply-to: ethan.mall...@sun.com
Original-recipient: rfc822;ethan.mall...@sun.com



SQL QUERY: 
 INSERT INTO speedy_results 
 (trial,
merge_stdout_stderr,
test_result,
phase,
exit_signal,
exit_value,
client_serial,
result_message,
result_stderr,
result_stdout,
environment,
start_timestamp,
submit_timestamp,
duration,
submit_id,
phase_id,
results_id) 
 VALUES 
 ('1 ',
DEFAULT,
'1',
'3',
'-1',
'0',
'7428',
'Passed',
'',
'Hello, C++ world!  I am 0 of 2
Hello, C++ world!  I am 1 of 2
',
DEFAULT,
'Fri Mar  9 16:50:05 2007',
'Fri Mar  9 17:31:37 2007',
'2 seconds',
'564',
'3360557',
'3469545') 

SQL ERROR: ERROR:  invalid input syntax for type boolean: "1 "
SQL ERROR: 

- End forwarded message -

Re: [MTT users] New version of MTT

[Ethan Mallove]

Folks,

MTT version 2.1 is live! Please do an "svn up" at your
earliest convenience. As always, report any issues you
encounter to this mailing list.

Thanks,
Ethan


On Wed, May/09/2007 09:09:46PM, Jeff Squyres wrote:
> All --
> 
> We are just about to release MTT version 2.1.  Woo hoo!
> 
> There are a bunch of new features available -- see this
> wiki page for  details:
> 
>  https://svn.open-mpi.org/trac/mtt/wiki/News-09-May-2007
> 
> We strongly encourage everyone to update their INI files
> for new  "pass" and "skip" criteria with the new &cmd_*()
> funclets that are  available (examples are on the wiki
> page).
> 
> Ethan will reply shortly with the timeframe for when we
> plan to cut  the new version over on the
> "ompi-core-testers" branch.
> 
> -- 
> Jeff Squyres
> Cisco Systems
> 
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

Re: [MTT users] mtt test build for IMB-MPI1 fails,

[Ethan Mallove]

Just a guess, but could this could be the source of confusion?

https://svn.open-mpi.org/svn/ompi-tests/trunk/PMB-2.2
https://svn.open-mpi.org/svn/ompi-tests/trunk/IMB_2.3

Should PMB be removed from ompi-tests? I mean, would there
ever be a reason to use PMB 2.2 instead of IMB 2.3?

-Ethan


On Mon, May/21/2007 06:32:53AM, Jeff Squyres wrote:
> It looks like your makefile is hard-coded to use /bin/mpicc, which  
> will always be wrong for MTT.  This specifies an absolute location  
> for mpicc, and does not allow the $PATH to be used.
> 
> Where are you getting your copy of IMB from?
> 
> The IMB 2.3 that is in the ompi_tests repository has a make_openmpi  
> that contains the following line:
> 
> CC  = mpicc
> 
> Hence, "mpicc" is used, and therefore $PATH is used to find it.
> 
> Can you modify your makefile this way?
> 
> 
> On May 20, 2007, at 12:31 AM, Shai Venter wrote:
> 
> > Hello again Mr Squyres.
> >
> > I am most greatfull for your answers to my questions (2).
> > Actualy, they are both linked to the same issue: my mtt run fails  
> > in the
> > test build phase for IMB-MPI1.
> >
> > It seems that the make file cannot find the mpicc to compile.
> > It searches for it in a default path (/bin/mpicc) but it's
> > Usless scince this path is irrelevant.
> >
> > I've tried this code:
> >
> > module = Shell
> > shell_build_command = < > cd src
> > make clean IMB-MPI1
> > EOT
> >
> > But still the same error.
> >
> >
> > Lets have a look at the output of build error:
> >
> > -- 
> > --
> > 
> > sw169:/usr/local/mtt # cat
> > scratch/installs/K5a_/tests/imb-2.3/test_built.ini
> > # This file was automatically created by Config/IniFiles.pm.  Any
> > changes made manually are likely to be lost!
> > [test_built]
> > mpi_version=1.2.2
> > full_section_name=test build: imb-2.3
> > result_stdout= < > /bin/rm -f *.o *~ PI* core IMB-IO IMB-EXT IMB-MPI1 exe_io exe_ext
> > exe_mpi1
> > touch exe_mpi1 *.c; rm -rf exe_io exe_ext
> > make MPI1 CPP=MPI1
> > make[1]: Entering directory
> > `/usr/local/mtt/scratch/installs/K5a_/tests/imb-2.3/IMB-2.3/src'
> > /bin/mpicc  -I/include   -DMPI1 -O -g -c IMB.c
> > make[1]: /bin/mpicc: Command not found
> > make[1]: *** [IMB.o] Error 127
> > make[1]: Leaving directory
> > `/usr/local/mtt/scratch/installs/K5a_/tests/imb-2.3/IMB-2.3/src'
> > make: *** [IMB-MPI1] Error 2
> > EOT
> > refcount=0
> > result_message= < > Shell: command failed "cd src
> > make clean IMB-MPI1"
> > EOT
> > mpi_install_simple_section_name=gcc
> > test_result=0
> > exit_status=512
> > mpi_get_simple_section_name=ompiv1.2
> > simple_section_name=imb-2.3
> > srcdir=/usr/local/mtt/scratch/installs/K5a_/tests/imb-2.3/IMB-2.3
> > start_timestamp=1179655379
> > test_get_simple_section_name=imb
> >
> > -- 
> > --
> > 
> >
> >
> >
> > I feel that it has some thing to do with setting up an enviroment path
> > variable to the mpi bin dir. I could provide it as an argument to the
> > "make" file, but I cannot know in advance where mtt creates/ 
> > installs the
> > bin dir for each and every mpi installtion.
> >
> > Hopefully, you'll have an insight on this.
> >
> > Regards,
> > Shai Venter.
> >
> >
> >
> > -Original Message-
> >
> > Today's Topics:
> >
> >1. MTT with ompiv1.2 (Shai Venter)
> >2. Re: MTT with ompiv1.2 (Jeff Squyres)
> >3. How can I know the path to mpicc ? (Shai Venter)
> >4. Re: How can I know the path to mpicc ? (Jeff Squyres)
> >
> >
> > --
> >
> > Message: 1
> > Date: Thu, 17 May 2007 16:50:14 +0300
> > From: "Shai Venter" 
> > Subject: [MTT users] MTT with ompiv1.2
> > To: 
> > Message-ID:
> > <6c2c79e72c305246b504cba17b5500c901825...@mtlexch01.mtl.com>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > Hi There !
> > Regarding the .ini file:
> > Using setenv in the MPI Get: phase, should set me an Enviroment var,
> > right ?!
> > So if , let say, I write setenv = MPIHOMEDIR  &shell("pwd")/install
> > should set MPIHOMEDIR to some path as mentioned.
> > Well, I checked for my MPIHOMEDIR  in the env ( cmd line:   env |grep
> > MPI ) and got nothing.
> > What did I not do right?
> >
> >
> >
> > Shai Venter
> > Q.A
> > Mellanox Technologies, Ltd.
> > www.mellanox.com
> > +972 (0)4  9097200 ext. 252
> > +972 (0)50 2888637
> >
> > Date: Thu, 17 May 2007 07:04:22 -0700
> > From: Jeff Squyres 
> > Subject: Re: [MTT users] MTT with ompiv1.2
> > To: General user list for the MPI Testing Tool
> > 
> > Message-ID: <4d863c26-ee6f-4f3e-9238-82480dc7d...@cisco.com>
> > Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes;
> > format=flowed
> >
> > I don't believe that we currently support setenv in the MPI Get
> > phase, mainly because we didn't know that anyone would be using it
> > there.
> >
> > What do you need to do, specifically?
> >
> > F

[MTT users] Failure tracking (RE: #70: Show "new" failures)

[Ethan Mallove]

I have something to help filter out (in reporter.php) old
known OMPI failures, though this feature is still in an
embryonic stage.

E.g., here's a link that shows *all* of Sun's recent Test
Run failures.

http://www.open-mpi.org/~emallove/mtt_/reporter.php?do_redir=199

If I don't care to sift through all the SPARC "alignment"
errors that are already in our bug tracking system, I can
add that failure here at the below link. 

http://www.open-mpi.org/~emallove/mtt_/track-failures/?screen=Insert

The HTML form would like something like this:

  Field: "Hardware" Value: _sun4u_
  Field: "Stdout"   Value: _invalid address alignment_
  (The remaining 8 rows of the form would be left blank)

One can see the entire database of failures in 
"Delete Mode". E.g.,

http://www.open-mpi.org/~emallove/mtt_/track-failures/?screen=Delete

E.g., now if I don't care to see the alignment errors, I can
checkbox the "Filter tracked failures" box in Preferences.
Voil?:

http://www.open-mpi.org/~emallove/mtt_/reporter.php?do_redir=200

Thoughts?

-Ethan

Re: [MTT users] Failure tracking (RE: #70: Show "new" failures)

[Ethan Mallove]

On Tue, May/22/2007 07:36:42AM, Jeff Squyres wrote:
> I'm assuming that this is a per-user kind of setting,
> right? (e.g.,  stored in a cookie)
> 

Correct. The on/off switch is a user pref. Though the
database of filters itself is global. Do you think the
filters should be per-user too?


> It looks promising, but I'd put better titles on the two
> screens.   E.g., I'd call this results filtering, or
> somesuch.
>

Right, this is more like a global "Ignore".  I guess I
called it "failure tracking" in the hopes that MTT would
someday be able to magically populate the "failure" table by
itself.


> 
> On May 21, 2007, at 3:42 PM, Ethan Mallove wrote:
> 
> > I have something to help filter out (in reporter.php) old
> > known OMPI failures, though this feature is still in an
> > embryonic stage.
> >
> > E.g., here's a link that shows *all* of Sun's recent Test
> > Run failures.
> >
> > http://www.open-mpi.org/~emallove/mtt_/reporter.php?do_redir=199
> >
> > If I don't care to sift through all the SPARC "alignment"
> > errors that are already in our bug tracking system, I can
> > add that failure here at the below link.
> >
> > http://www.open-mpi.org/~emallove/mtt_/track-failures/?screen=Insert
> >
> > The HTML form would like something like this:
> >
> >   Field: "Hardware" Value: _sun4u_
> >   Field: "Stdout"   Value: _invalid address alignment_
> >   (The remaining 8 rows of the form would be left blank)
> >
> > One can see the entire database of failures in
> > "Delete Mode". E.g.,
> >
> > http://www.open-mpi.org/~emallove/mtt_/track-failures/?screen=Delete
> >
> > E.g., now if I don't care to see the alignment errors, I can
> > checkbox the "Filter tracked failures" box in Preferences.
> > Voil?:
> >
> > http://www.open-mpi.org/~emallove/mtt_/reporter.php?do_redir=200
> >
> > Thoughts?
> >
> > -Ethan
> > ___
> > mtt-users mailing list
> > mtt-us...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
> 
> 
> -- 
> Jeff Squyres
> Cisco Systems
> 
> 
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

[MTT users] Few trunk results this morning?

[Ethan Mallove]

There's hardly any ompi-nightly-trunk results this morning
from *any* of the "ompi-core-testers". Did something happen
with the tarball generator last night?

-Ethan

[MTT users] &if funclet and quoting

[Ethan Mallove]

--
Question 1:
--

I have the below "exec" and "btls" params in my INI, but I
keep running into quoting issues. I'm trying to get an
if-else effect by putting the else block in as the third
argument to the &if() function, and I can't seem to manage
the levels of nested quoting. I keep getting bareword errors
(which is due to an incorrect number of wrapped quotes).
What am I doing wrong?

exec = mpirun --mca btl @btls@ @hosts@ -np &test_np() --prefix &test_prefix() 
&test_executable() &test_argv()

btls = &if("®exp("&shell("hostname")", "v440-2|v20z-2")", \
   "&enumerate("self,sm,tcp")", \
   "&if("®exp("&shell("hostname")", "v440-6")", \
   "&enumerate("udapl")", \
   "&enumerate("sm", "tcp", "sm,tcp", "udapl", "sm,udapl")"" \
   ) \
   )

(The idea here is to use a different "--mca btl" option on
different clusters.)

--
Question 2:
--

How come EvaluateString() doesn't translate this:

btls = &if("®exp("&shell("hostname")", "v440-2|v20z-2")", \
   "&enumerate("self,sm,tcp")", \
   "&if("®exp("&shell("hostname")", "v440-6")", \
   "&enumerate("udapl")", \
   "&enumerate("sm", "tcp", "sm,tcp", "udapl", "sm,udapl")"" \
   ) \
   )

Into one big eval block like this:

eval $btls = 
MTT::Functions::if(MTT::Functions::regexp(MTT::Functions::shell("hostname"), 
"v440-2|v20z-2"),
 MTT::Functions::enumerate("self,sm,tcp"),
 
MTT::Functions::if("MTT::Functions::regexp("MTT::Functions::shell("hostname"), 
"v440-6"),
 MTT::Functions::enumerate("udapl"),
 MTT::Functions::enumerate("sm", "tcp", "sm,tcp", "udapl", 
"sm,udapl")
 )
 )

So we could put the burden of the nasty recursive
parenthesis/quote parsing on perl, rather than MTT. That
would seem to naturally make the INI funclet syntax more
Perl-like.

-Ethan

Re: [MTT users] &if funclet and quoting

[Ethan Mallove]

On Tue, Jun/12/2007 08:07:20AM, Jeff Squyres wrote:
> On Jun 11, 2007, at 6:02 PM, Ethan Mallove wrote:
> 
> > btls = &if("®exp("&shell("hostname")", "v440-2|v20z-2")", \
> >"&enumerate("self,sm,tcp")", \
> >"&if("®exp("&shell("hostname")", "v440-6")", \
> >"&enumerate("udapl")", \
> >"&enumerate("sm", "tcp", "sm,tcp", "udapl",  
> > "sm,udapl")"" \
> >) \
> >)
> 
> Yowza!  We really need to make this quoting situation better  
> somehow.  :-(
> 
> Don't you have an extra ) in there at the end?
> 
> > How come EvaluateString() doesn't translate this:
> >
> > btls = &if("®exp("&shell("hostname")", "v440-2|v20z-2")", \
> >"&enumerate("self,sm,tcp")", \
> >"&if("®exp("&shell("hostname")", "v440-6")", \
> >"&enumerate("udapl")", \
> >"&enumerate("sm", "tcp", "sm,tcp", "udapl",  
> > "sm,udapl")"" \
> >) \
> >)
> >
> > Into one big eval block like this:
> >
> > eval $btls = MTT::Functions::if(MTT::Functions::regexp 
> > (MTT::Functions::shell("hostname"), "v440-2|v20z-2"),
> >  MTT::Functions::enumerate("self,sm,tcp"),
> >  MTT::Functions::if("MTT::Functions::regexp 
> > ("MTT::Functions::shell("hostname"), "v440-6"),
> >  MTT::Functions::enumerate("udapl"),
> >  MTT::Functions::enumerate("sm", "tcp",  
> > "sm,tcp", "udapl", "sm,udapl")
> >  )
> >  )
> >
> > So we could put the burden of the nasty recursive
> > parenthesis/quote parsing on perl, rather than MTT. That
> > would seem to naturally make the INI funclet syntax more
> > Perl-like.
> 
> Ah -- I had to think about this a bit before I figured it out/ 
> remembered.  I think we won't get the expansion effect if you do it  
> this way.  

No expansion effect? As long as the perl code evaluates to
an array, couldn't it to work? E.g.,

  exec = mpirun --mca btl @btls@ ...

  # Returns an array
  btls = ("sm", "tcp")

So EvaluateString() would do only this:

  * Substitute all &funcs() with MTT::Functions::funcs()
  * Substitute all $vars with same-INI-section params
  * Backslash escape @ symbols so they show up as strings in
the eval'd result
  * Perform an "eval" on the final string
  * Iterate over the result of the above step's string,
replacing "@multiplier" strings with the corresponding
element of the @multiplier array 

> Although it might solve some other issues (e.g., https:// 
> svn.open-mpi.org/trac/mtt/ticket/184)...?
>

The mess atop this email would simplify to:

btls =  if ($hostname =~ /foo/) {\
return ("self,sm,tcp");  \
} elsif ($hostname =~ /bar/) {   \
return ("udapl");\
} else { \
return ("sm", "tcp", "sm,tcp", "udapl", "sm,udapl"); \
}

-Ethan


> -- 
> Jeff Squyres
> Cisco Systems
> 
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

Re: [MTT users] &if funclet and quoting

[Ethan Mallove]

On Tue, Jun/12/2007 04:53:21PM, Jeff Squyres wrote:
> On Jun 12, 2007, at 10:50 AM, Ethan Mallove wrote:
> 
> >>> eval $btls = MTT::Functions::if(MTT::Functions::regexp
> >>> (MTT::Functions::shell("hostname"), "v440-2|v20z-2"),
> >>>  MTT::Functions::enumerate("self,sm,tcp"),
> >>>  MTT::Functions::if("MTT::Functions::regexp
> >>> ("MTT::Functions::shell("hostname"), "v440-6"),
> >>>  MTT::Functions::enumerate("udapl"),
> >>>  MTT::Functions::enumerate("sm", "tcp",
> >>> "sm,tcp", "udapl", "sm,udapl")
> >>>  )
> >>>  )
> >>
> >> Ah -- I had to think about this a bit before I figured it out/
> >> remembered.  I think we won't get the expansion effect if you do it
> >> this way.
> >
> > No expansion effect? As long as the perl code evaluates to
> > an array, couldn't it to work? E.g.,
> 
> We'll need to revamp all the current funclets to accept
> arrays and  return [potentially] arrays of arrays.  What
> if, as a  counterproposal, we have a &perl() funclet?
> Then you could do the  following:
> 
> 
> 
> btls = &perl("if ($hostname =~ /foo/) { \
> return ("self,sm,tcp");  \
> } elsif ($hostname =~ /bar/) {   \
> return ("udapl");\
> } else { \
> return ("sm", "tcp", "sm,tcp", "udapl", "sm,udapl"); \
> }")
>
> 
> 
> (or something like that)
>

I like that. Is that in anticipation of having &ksh(),
&zsh(), &python(), &php(), &tcl(), ... ?  To reduce some
clutter, maybe a param like this would be fun, e.g.,

  default_ini_evaluator = perl

So MTT will assume you mean &perl() if there's
no leading '&'.

Other legal options being ...

  default_ini_evaluator = python
  default_ini_evaluator = sh
  default_ini_evaluator = tcl
  default_ini_evaluator = ...

-Ethan


> 
> 
> 
> -- 
> Jeff Squyres
> Cisco Systems
> 
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

Re: [MTT users] Differentiating builds in the reporter

[Ethan Mallove]

On Fri, Jun/15/2007 10:01:24AM, Jeff Squyres wrote:
> On Jun 14, 2007, at 10:45 PM, Tim Prins wrote:
> 
> > Here at IU on our cluster Thor, we are running the trunk
> > both with  threads enabled and with threads disabled.
> > How should these builds be  differentiated for the
> > reporter?
> 
> Do you have two different MPI install sections for the
> with/without  threads?  (that's how I have it configured
> in my Cisco MTT -- not  running in production yet, but it
> will be soon)
> 
> If so, they should be naturally separated already.
>

Or try this.

With threads:

http://www.open-mpi.org/mtt/reporter.php?do_redir=226

Without threads:

http://www.open-mpi.org/mtt/reporter.php?do_redir=227

If you click [Advanced] pop-up window you can see I've
entered "threads" and "!threads".

-Ethan


> -- 
> Jeff Squyres
> Cisco Systems
> 
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

[MTT users] INI trick for single-node testing

[Ethan Mallove]

Hi,

I have a way to toggle single-node testing at the command
line. E.g., it looks like this:

  $ client/mtt run_on_single_node=1 ...
  $ client/mtt run_on_single_node=0 ...

I just needed the below INI mojo to get this going.

Added a "run_on_single_node" boolean to my [MTT] section.
("ompinfo" is an internal Sun script that spits out
hard-coded hostlist's based on what node the user is on.)

{{{
[MTT]
...
# Boolean which tells MTT to run on a single node
run_on_single_node = 0

ompinfo = /ws/ompi-tools/bin/ompinfo
hostlist = <

[MTT users] max_np on multi-processor nodes

[Ethan Mallove]

env_max_procs uses this order of precedence to get a
"max_np".

  1. Various resource managers
  2. If a global hostfile was specified
  3. If a global hostlist was specified
  4. If a global max_np was specified

Shouldn't 4 be at the top of the list?

I'm doing single node testing, but the fact that I have only
one node listed in hostlist causes env_max_procs to return
"1". I'd like to override the 1 value with the number of
CPU's on the single node I'm running on.

-Ethan

Re: [MTT users] max_np on multi-processor nodes

[Ethan Mallove]

On Thu, Jun/28/2007 08:07:11AM, Jeff Squyres wrote:
> On Jun 28, 2007, at 12:42 AM, Ethan Mallove wrote:
> 
> > env_max_procs uses this order of precedence to get a
> > "max_np".
> >
> >   1. Various resource managers
> >   2. If a global hostfile was specified
> >   3. If a global hostlist was specified
> >   4. If a global max_np was specified
> >
> > Shouldn't 4 be at the top of the list?
> 
> > I'm doing single node testing, but the fact that I have only
> > one node listed in hostlist causes env_max_procs to return
> > "1". I'd like to override the 1 value with the number of
> > CPU's on the single node I'm running on.
> 
> Is the :N notation not sufficient?
> 
> # OMPI Core: if you would rather list the hosts individually on the
> # mpirun command line, list hosts here delimited by whitespace (if you
> # have a hostfile listed above, this value will be ignored!).  Hosts
> # can optionally be suffixed with ":num", where "num" is an integer
> # indicating how many processes may be started on that machine (if not
> # specified, ":1" is assumed).  The sum of all of these values is used
> # for &env_max_np() at run time.  Example (4 uniprocessors):
> #hostlist = node1 node2 node3 node4
> # Another example (4 2-way SMPs):
> #hostlist = node1:2 node2:2 node3:2 node4:2
> # The "hostlist" value is ignored if you are running in a scheduled
> # environment or if you have specified a hostfile.


Oops. That's what I need. 

But re the above precedence list, if I wanted to
oversubscribe using a hostlist and a manually overriden
max_np param, wouldn't we still need to put item #4 at the
top of the list?

-Ethan


> 
> -- 
> Jeff Squyres
> Cisco Systems
> 
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

Re: [MTT users] Database insert errors

[Ethan Mallove]

Hi Tim,

I see some of these FOREIGN KEY constraint errors every
night. There's a system of speedy and archive tables to keep
short-term queries fast, but it has bugs. There are rows in
the archive tables that should be mirrored in the speedy
tables, but this is not always the case. We (well, mostly
Josh) are working on an improved system of "partitioning"
the huge Postgres tables to keep queries fast which will
hopefully also resolve these referential integrity problems.

-Ethan


On Sun, Jul/01/2007 09:37:17PM, Tim Prins wrote:
> Hi Folks,
> 
> For a while now we have been getting errors when MTT tries to submit its test 
> results to the database. The weird thing is that it only happens on our 1.2 
> runs, not our trunk runs. 
> 
> Here is the first few lines of the error output:
> *** WARNING: MTTDatabase server notice: fields is not in mtt3 database.
> MTTDatabase server notice: test_build_section_name is not in mtt3
> database.
> MTTDatabase server notice: mpi_install_section_name is not in mtt3
> database.
> MTTDatabase server notice: mtt_version_minor is not in mtt3 database.
> MTTDatabase server notice: stop_timestamp is not in mtt3 database.
> MTTDatabase server notice: mtt_version_major is not in mtt3 database.
> MTTDatabase server notice: number_of_results is not in mtt3 database.
> MTTDatabase server notice: test_run_section_name is not in mtt3
> database.
> 
> MTT submission for test run
> MTTDatabase server error:
> SQL QUERY:
>  INSERT INTO speedy_test_run
>  (np,
> variant,
> test_build_id,
> command,
> test_name,
> test_run_id)
>  VALUES
>  ('8',
> '1',
> '20809',
> 'mpirun  -mca pml ob1 -mca btl_tcp_if_include eth0 -mca btl
> tcp,sm,self -np 8 --prefix
> /san/homedirs/mpiteam/mtt-runs/thor/20070630-Nightly/pb_0/installs/k1mL
> /install collective/allgather ',
> 'allgather',
> '14517807')
> 
> SQL ERROR: ERROR:  insert or update on table "speedy_test_run" violates
> foreign key constraint "$1"
> DETAIL:  Key (test_build_id)=(20809) is not present in table
> "speedy_test_build".
> 
> Another strange thing is that the output says that the build information and 
> some test results have been submitted, but I do not see them in the reporter. 
> Any ideas?
> 
> Thanks,
> 
> Tim
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

Re: [MTT users] Perl Wrap Error

[Ethan Mallove]

On Fri, Jul/06/2007 01:22:06PM, Joshua Hursey wrote:
> Anyone seen the following error from MTT before? It looks like it is in the 
> reporter stage.
>
> <->
> shell$ /spin/home/jjhursey/testing/mtt//client/mtt --mpi-install  --scratch 
> /spin/home/jjhursey/testing/scratch/20070706 --file 
> /spin/home/jjhursey/testing/etc/jaguar/simple-svn.ini --print-time 
> --verbose --debug 2>&1 1>> 
> /spin/home/jjhursey/testing/scratch/20070706/output.txt
> This shouldn't happen at /usr/lib/perl5/5.8.3/Text/Wrap.pm line 64.
> shell$
> <->

"This shouldn't happen at ..." is the die message?

Try this INI [Reporter: TextFile] section:

{{{
  [Reporter: text file backup]
  module = TextFile

  textfile_filename = $phase-$section-$mpi_name-$mpi_version.txt

  # User-defined report headers/footers
  textfile_summary_header = <
> The return code is: 6400
>
> I attached the output log incase that helps, and the INI file.
>
> -- Josh

Re: [MTT users] Database insert errors

[Ethan Mallove]

I don't think so, because I see the same errors from sites
using the latest MTT version. 

-Ethan


On Mon, Jul/09/2007 09:07:20AM, Tim Prins wrote:
> Could these errors have to do with the fact that we are running MTT 
> v2.0.1, and not the latest version?
> 
> Thanks,
> 
> Tim
> 
> Ethan Mallove wrote:
> > Hi Tim,
> > 
> > I see some of these FOREIGN KEY constraint errors every
> > night. There's a system of speedy and archive tables to keep
> > short-term queries fast, but it has bugs. There are rows in
> > the archive tables that should be mirrored in the speedy
> > tables, but this is not always the case. We (well, mostly
> > Josh) are working on an improved system of "partitioning"
> > the huge Postgres tables to keep queries fast which will
> > hopefully also resolve these referential integrity problems.
> > 
> > -Ethan
> > 
> > 
> > On Sun, Jul/01/2007 09:37:17PM, Tim Prins wrote:
> >> Hi Folks,
> >>
> >> For a while now we have been getting errors when MTT tries to submit its 
> >> test 
> >> results to the database. The weird thing is that it only happens on our 
> >> 1.2 
> >> runs, not our trunk runs. 
> >>
> >> Here is the first few lines of the error output:
> >> *** WARNING: MTTDatabase server notice: fields is not in mtt3 database.
> >> MTTDatabase server notice: test_build_section_name is not in mtt3
> >> database.
> >> MTTDatabase server notice: mpi_install_section_name is not in mtt3
> >> database.
> >> MTTDatabase server notice: mtt_version_minor is not in mtt3 database.
> >> MTTDatabase server notice: stop_timestamp is not in mtt3 database.
> >> MTTDatabase server notice: mtt_version_major is not in mtt3 database.
> >> MTTDatabase server notice: number_of_results is not in mtt3 database.
> >> MTTDatabase server notice: test_run_section_name is not in mtt3
> >> database.
> >>
> >> MTT submission for test run
> >> MTTDatabase server error:
> >> SQL QUERY:
> >>  INSERT INTO speedy_test_run
> >>  (np,
> >> variant,
> >> test_build_id,
> >> command,
> >> test_name,
> >> test_run_id)
> >>  VALUES
> >>  ('8',
> >> '1',
> >> '20809',
> >> 'mpirun  -mca pml ob1 -mca btl_tcp_if_include eth0 -mca btl
> >> tcp,sm,self -np 8 --prefix
> >> /san/homedirs/mpiteam/mtt-runs/thor/20070630-Nightly/pb_0/installs/k1mL
> >> /install collective/allgather ',
> >> 'allgather',
> >> '14517807')
> >>
> >> SQL ERROR: ERROR:  insert or update on table "speedy_test_run" violates
> >> foreign key constraint "$1"
> >> DETAIL:  Key (test_build_id)=(20809) is not present in table
> >> "speedy_test_build".
> >>
> >> Another strange thing is that the output says that the build information 
> >> and 
> >> some test results have been submitted, but I do not see them in the 
> >> reporter. 
> >> Any ideas?
> >>
> >> Thanks,
> >>
> >> Tim
> >> ___
> >> mtt-users mailing list
> >> mtt-us...@open-mpi.org
> >> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
> > ___
> > mtt-users mailing list
> > mtt-us...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
> 
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

Re: [MTT users] Textfile Reporter

[Ethan Mallove]

Whoops! I didn't realize anyone was using that Textfile
module. We can resurrect that if you'd like (call it
ParseableTextfile).

There's also the INIFile Reporter. That might be your best
bet, since there's a Config::INIFiles CPAN module. (Your
wrappers are in Perl, right?) Though wouldn't it be even
easier if there were a PerlDumper Reporter module so you
could read in the data *directly* to your Perl wrappers?
Your wrapper would do no parsing then. E.g.,

open(FILE, "< $file");
undef $/;
$mtt_results = ;

-Ethan


On Mon, Jul/09/2007 06:07:51PM, Tim Prins wrote:
> Hi,
> 
> With the new version of MTT, the textfile report file
> format changed to a more human readable format. Since we
> here at IU use a script to parse this, it presents a bit
> of a problem. I can update our script, but was wondering
> how stable this new output format is.
> 
> If it will not be very stable, I was wondering if the
> developers would consider adding a parseable textfile
> output module. The easiest thing to do for this would be
> to just import the old textfile module as a new parseable
> module. I have tried this and it seems to work fine,
> however there may be problems with this that I am unaware
> of.
> 
> I can deal with this either way, but just thought it might
> make things easier to have a parseable format that is
> relatively static, and a human readable format that can be
> tweaked for useability as time goes by.
> 
> Thanks,
> 
> Tim
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

Re: [MTT users] Textfile Reporter

[Ethan Mallove]

Done. 

I brought it back as "ParsableTextfile" in both the trunk
and ompi-core-testers. You'll just have to do two things in
your INI file:

 * Change "module = Textfile" to "module = ParsableTextfile"
 * Rename "textfile_" params to "parsabletextfile_" params

Let me know if you run into any other issues with this.

-Ethan


On Tue, Jul/10/2007 02:27:27PM, Tim Prins wrote:
> Hmm, the INI file reporter does not seem to work for me. For the test results 
> I only get the information about the last test run. 
> 
> Anyways, I like the idea of pulling the data directly in from perl output but 
> just don't have the time to mess with it right now. For me bringing back the 
> old reporter would be easiest for the time being. However, I also need the 
> following patch applied to resurect a couple output fields that were removed 
> which we need:
> 
> Index: lib/MTT/Test/Analyze/Correctness.pm
> ===
> --- lib/MTT/Test/Analyze/Correctness.pm (revision 737)
> +++ lib/MTT/Test/Analyze/Correctness.pm (working copy)
> @@ -53,6 +53,8 @@
> 
>  test_name => $run->{name},
>  command => $run->{cmd},
> +test_build_section_name => $run->{test_build_simple_section_name},
> +
>  np => $run->{np},
>  exit_value => MTT::DoCommand::exit_value($results->{exit_status}),
>  exit_signal => MTT::DoCommand::exit_signal($results->{exit_status}),
> Index: lib/MTT/MPI/Install.pm
> ===
> --- lib/MTT/MPI/Install.pm  (revision 737)
> +++ lib/MTT/MPI/Install.pm  (working copy)
> @@ -505,6 +505,8 @@
>  my $report = {
>  phase => "MPI Install",
> 
> +mpi_install_section_name => $config->{simple_section_name},
> +
>      bitness => $config->{bitness},
>  endian => $config->{endian},
>  compiler_name => $config->{compiler_name},
> 
> 
> Thanks,
> 
> Tim
> 
> On Tuesday 10 July 2007 11:46:34 am Ethan Mallove wrote:
> > Whoops! I didn't realize anyone was using that Textfile
> > module. We can resurrect that if you'd like (call it
> > ParseableTextfile).
> >
> > There's also the INIFile Reporter. That might be your best
> > bet, since there's a Config::INIFiles CPAN module. (Your
> > wrappers are in Perl, right?) Though wouldn't it be even
> > easier if there were a PerlDumper Reporter module so you
> > could read in the data *directly* to your Perl wrappers?
> > Your wrapper would do no parsing then. E.g.,
> >
> > open(FILE, "< $file");
> > undef $/;
> > $mtt_results = ;
> >
> > -Ethan
> >
> > On Mon, Jul/09/2007 06:07:51PM, Tim Prins wrote:
> > > Hi,
> > >
> > > With the new version of MTT, the textfile report file
> > > format changed to a more human readable format. Since we
> > > here at IU use a script to parse this, it presents a bit
> > > of a problem. I can update our script, but was wondering
> > > how stable this new output format is.
> > >
> > > If it will not be very stable, I was wondering if the
> > > developers would consider adding a parseable textfile
> > > output module. The easiest thing to do for this would be
> > > to just import the old textfile module as a new parseable
> > > module. I have tried this and it seems to work fine,
> > > however there may be problems with this that I am unaware
> > > of.
> > >
> > > I can deal with this either way, but just thought it might
> > > make things easier to have a parseable format that is
> > > relatively static, and a human readable format that can be
> > > tweaked for useability as time goes by.
> > >
> > > Thanks,
> > >
> > > Tim
> > > ___
> > > mtt-users mailing list
> > > mtt-us...@open-mpi.org
> > > http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
> >
> > ___
> > mtt-users mailing list
> > mtt-us...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users

[MTT users] WriteINI() calls in MPI/Install and Test/Build

[Ethan Mallove]

Do we still need to write out an INI file after each MPI
Install and Test Build? I thought we're using .dump files
instead? (I noticed this because it seemed to be taking a few
minutes to write the INI file after building the intel
tests.)

-Ethan

Re: [MTT users] WriteINI() calls in MPI/Install and Test/Build

[Ethan Mallove]

On Fri, Aug/10/2007 01:02:16PM, Jeff Squyres wrote:
> On Aug 10, 2007, at 10:14 AM, Ethan Mallove wrote:
> 
> > Do we still need to write out an INI file after each MPI
> > Install and Test Build? I thought we're using .dump
> > files instead? (I noticed this because it seemed to be
> > taking a few minutes to write the INI file after
> > building the intel tests.)
> 
> IIRC, those are test-build-specific files and down far
> deep in the  scratch tree.  The intent was to capture
> *everything* there  (including all of stdout/stderr) in
> case there was something valuable  there that we didn't
> capture sending up to the DB.
> 
> However, I could see how it wouldn't be too valuable these
> days.
> 
> How about turning it off, but leaving an option in the
> [MTT] section  to re-enable it if we ever need it again?
>

Looking a little closer, there are inconsistencies in what's
going to the saved .dump and .ini files:

  Test Run .dump (split up by variants):

* Everything (including stdout/stderr)

  Test Run .ini:

* Nothing

  Test Build .dump:

* Everything (except stdout/stderr)

  Test Build .ini (split up by test suites):

* Everything execept database serials, mpi_name,
  and environment (e.g., prepend_path, env_module, etc)

  MPI Install .ini:

* Nothing

  MPI Install .dump:

* Everything

How about we put *everything* in the .dump files, while
offering to also save *everything* in INI files in the [MTT]
section? Though Perl-Dumper is only slightly less
human-readble than INI.  

These are also a little confusing:

  save_stdout_on_success 
  stderr_save_lines

Don't we want these instead broken up into two: inifile and
mttdatabase? So a user might choose to save more or less on
their disk than to the database?

  save_stdout_on_success_to_mttdatabase
  stderr_save_lines_to_mttdatabase

  save_stdout_on_success_to_inifile
  stderr_save_lines_to_inifile

-Ethan


> -- 
> Jeff Squyres
> Cisco Systems
> 
> ___
> mtt-users mailing list
> mtt-us...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-users