Open MPI logo

MTT Devel Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all MTT Devel mailing list

Subject: Re: [MTT devel] question about the test run
From: DongInn Kim (dikim_at_[hidden])
Date: 2010-11-04 14:48:56


OK, thanks. Jeff.

I am not sure that this is related to my original question but I was actually looking for a way to have ftt find my test examples with the following.
#======================================================================
# Test Run phase
#======================================================================

# Some default Test run parameters to include in (most) Test run sections
[Test run]
pass = &and(&cmd_wifexited(), &eq(&cmd_wexitstatus(), 0))
timeout = &max(30, &multiply(10, &test_np()))
save_stdout_on_pass = 1
merge_stdout_stderr = 1
stdout_save_lines = 100
np = &env_max_procs()
specify_module = Simple

[Test run: ftb-examples]
include_section = Test run
test_build = ftb-examples

skipped = &and(&cmd_wifexited(), &eq(&cmd_wexitstatus(), 77))

# Similar rationale to the intel test run section
simple_first:tests = &find_executables( \
                    "ftb_eventhandle_example", \
                    "ftb_example_callback_unsubscribe", \
                    "ftb_multiplecomp", \
                    "ftb_notify_logger", \
                    "ftb_pingpong", \
                    "ftb_polling_logger", \
                    "ftb_simple_publisher", \
                    "ftb_simple_subscriber", \
                    "ftb_watchdog")

# Similar rationale to the intel test run section
simple_fail:tests = environment/abort environment/final
simple_fail:pass = &and(&cmd_wifexited(), &ne(&cmd_wexitstatus(), 0))
simple_fail:exclusive = 1
simple_fail:np = &env_max_procs()

The test example codes are listed in simple_first:tests.

But I don't think that those example codes are called to run at the "Test Run" phase.

Regards,

On 11/4/10 2:35 PM, Jeff Squyres wrote:
> It's instantiated in lib/MTT/Test.pm.
>
> It's filled in by LoadBuilds in the same file (i.e., when the results of a prior test build is loaded in from the dump file) and at the bottom of lib/MTT/Test/Build.pm::_do_build(), when the build has completed and it saves the results to the MTT:Test::builds hash.
>
>
>
> On Nov 4, 2010, at 1:59 PM, DongInn Kim wrote:
>
>> I am sorry that I was confused with the variable definition. My question should be how "$MP::Test::builds" is defined.
>>
>> Regards,
>>
>> On 11/4/10 1:42 PM, DongInn Kim wrote:
>>> Thank you for all the detailed explanations, Jeff.
>>>
>>> Yes, if we can manage the MPI part with more generic term, that would be really great so that we can use the same main framework without diverging to another perl module to deal with FTT or something like this.
>>>
>>> Basically, how the "$MTT" is defined and setup in "$MTT::Test::builds"?
>>>
>>> It is used in MTT/Test/Run.pm and I could not find how it is defined. If I find it, I think I can figure out what is going on here.
>>>
>>> Regards,
>>>
>>> On 11/4/10 11:54 AM, Jeff Squyres wrote:
>>>> 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. :-\
>>>>
>>>
>>
>> --
>> - DongInn
>
>

-- 
- DongInn