On Nov 4, 2010, at 8:46 AM, Joshua Hursey wrote:
> Just for context. DongInn and Abhishek are working on support for testing of
> the CIFTS FTB project with MTT. So this would be a non-MPI testing target.
> They are currently working through some of the issues with supporting an FTB
> target in the MTT client. I am working with them on getting a new server
> setup (i.e., database, reporter) for that project.
It might be worthwhile to s/MPI/Middleware/gi throughout the code, or, more
specifically, support both "Middleware Install" and "MPI Install" tags in the
ini file, etc.
(i.e., we can't ditch "MPI Install" and friends because of the OMPI community
using MTT, but if CIFTS and HDF are looking at using MTT, it might make sense
to finally make the names a bit more generic)
>> I found that the several keys of the hash($MTT::Test::builds) are empty in
>> the middle of mtt/lib/MTT/Test/Run.pm:123
>>
>> DB<12> p Dumper(\%{$MTT::Test::builds})
>> $VAR1 = {
>> '' => {
>> '' => {
As you surmise below, you're correct: the above two empty fields should be the
names from the MPI Get phase and the corresponding version.
>> 'platform' => {
You might want a bit more specific name than "platform" here. :-)
>> 'ftb-examples' => {
>> 'mpi_version' =>
>> undef,
IIRC, the MPI::Get module is responsible for setting this value in the data
structure that it returns, and it is propagated downward from there.
>> 'mpi_name' =>
>> undef,
I'm pretty sure that this is the name from the MPI::Install phase.
>> 'prepend_path'
>> => undef,
>> 'env_modules' =>
>> undef,
>> 'setenv' =>
>> undef,
>> 'unsetenv' =>
>> undef,
>> 'append_path' =>
>> undef,
These values all come directly from the INI file. If you didn't supply them,
it's ok for them to be undef.
prepend_path is stuff to be prepended to $path before running this section.
append_path is the same, except to be appended to $path.
setenv is stuff to be set in the environment before running this section.
unsetenv is pretty much the same.
env_modules are environment modules to be loaded before running this section.
All of these cause changes to be effected before the section starts. The
changes are effectively undone when the section ends (e.g., if an env module is
loaded, it is unloaded when the section ends).
These values also automatically propagate downwards -- any test runs that use
this test build section will "inherit" all of these values before any tests are
actually run, etc.
>> 'description' =>
>> undef,
This seems to come from the [MTT] section's "description" field. I forget
offhand what it is for. I have "description = Cisco MPI development cluster"
in my Cisco OMPI testing INI file.
>>
>> 'mpi_get_simple_section_name' => undef,
This is also the name from the MPI::Get phase.
>> 'mpi_install_id'
>> => undef,
The MPI::Install module is responsible for setting this... although I don't see
where any current MPI::Install module fills in that value. It might be left
over old kruft. :-\
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
