Open MPI logo

MTT Devel Mailing List Archives

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

From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2007-03-01 14:14:06

On Mar 1, 2007, at 2:03 PM, Ethan Mallove wrote:

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

Yes, this is what I think would be best -- create a chain of data
that was not submitted. Then the re-submit tool would be able to
grok the chain, get relevant ID numbers, paste them in downstream
(or, more likely, submit early phases, and have downstream phases
look upstream to get the relevant IDs -- just like it occurs in the
MTT client).

The more I think about this, the more that I think that having a
"submitted" flag in the local meta data in the MTT client might be
easiest. This might reduce the amount of logic we have to write
(i.e., the logic of grabbing the upstream phase IDs might be able to
be re-used and be less susceptible to breakage if we change formats/
protocols in the future -- i.e., it would only be 1 place to update,
not 2).

I know we have talked about this concept before, but it was always a
time/monkeys argument to actually implement it.

(not quite the "submitted" flag idea, but just the desire to be able
to resubmit)

Also similar to

A short term fix for Cisco might be to be able to try multiple
proxies in the event of "connection refused" (we have multiple
proxies available -- probably greatly reduces the chances of failure
if we have the ability to fail over to try others). This does not
help SVN checkouts, though -- we cannot configure those [easily] via
the INI file. That would take a bit more work (SVN checkouts do not
obey environment variable proxy settings -- you have to change a SVN
config file).

> 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 <cisco-password>
>>> /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]bdamico_at_[hidden]
>>>> Server virtualization Business Unit
>>>> References
>>>> 1. mailto:bdamico_at_[hidden]
>>>> _______________________________________________
>>>> mtt-users mailing list
>>>> mtt-users_at_[hidden]
>>> _______________________________________________
>>> mtt-users mailing list
>>> mtt-users_at_[hidden]
>> --
>> Jeff Squyres
>> Server Virtualization Business Unit
>> Cisco Systems
>> _______________________________________________
>> mtt-users mailing list
>> mtt-users_at_[hidden]
> _______________________________________________
> mtt-users mailing list
> mtt-users_at_[hidden]

Jeff Squyres
Server Virtualization Business Unit
Cisco Systems