[MTT devel] Fwd: [MTT commits] Git: open-mpi/mtt branch gh-pages updated. a919925665b72524e7c77358c94c1d677900156b

2018-08-16 Thread Jeff Squyres (jsquyres) via mtt-devel
Is there a way, perchance, to not re-generate / re-push the docs if nothing 
meaningful changes?

E.g., this commit is just changing the date, but no other content changed.



Begin forwarded message:

From: gitdub-nore...@aws.open-mpi.org 
('Gitdub ')
Subject: [MTT commits] Git: open-mpi/mtt branch gh-pages updated. 
a919925665b72524e7c77358c94c1d677900156b
Date: August 16, 2018 at 2:36:43 PM EDT
To: mtt-comm...@lists.open-mpi.org
Reply-To: mailto:mtt-de...@open-mpi.org>>

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "open-mpi/mtt".

The branch, gh-pages has been updated
  via  a919925665b72524e7c77358c94c1d677900156b (commit)
 from  3de9e99a5e7f2a5b1f21fa6253d3877bf2bf1621 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://github.com/open-mpi/mtt/commit/a919925665b72524e7c77358c94c1d677900156b

commit a919925665b72524e7c77358c94c1d677900156b
Author: Deployment Bot (from Travis CI) 
Date:   Thu Aug 16 18:36:39 2018 +

   Deploy open-mpi/mtt to github.com/open-mpi/mtt.git:gh-pages

diff --git a/latex/refman.tex b/latex/refman.tex
index 7d49b40..dbfac3c 100644
--- a/latex/refman.tex
+++ b/latex/refman.tex
@@ -67,8 +67,8 @@
\fancyhead[RO]{\fancyplain{}{\bfseries\thepage}}
\fancyfoot[LE]{\fancyplain{}{}}
\fancyfoot[CE]{\fancyplain{}{}}
-\fancyfoot[RE]{\fancyplain{}{\bfseries\scriptsize Generated on Thu Aug 16 2018 
18\-:36\-:21 for pymtt by Doxygen }}
-\fancyfoot[LO]{\fancyplain{}{\bfseries\scriptsize Generated on Thu Aug 16 2018 
18\-:36\-:21 for pymtt by Doxygen }}
+\fancyfoot[RE]{\fancyplain{}{\bfseries\scriptsize Generated on Thu Aug 16 2018 
18\-:36\-:28 for pymtt by Doxygen }}
+\fancyfoot[LO]{\fancyplain{}{\bfseries\scriptsize Generated on Thu Aug 16 2018 
18\-:36\-:28 for pymtt by Doxygen }}
\fancyfoot[CO]{\fancyplain{}{}}
\fancyfoot[RO]{\fancyplain{}{}}
\renewcommand{\footrulewidth}{0.4pt}
@@ -120,7 +120,7 @@
\vspace*{1cm}
{\large Generated by Doxygen 1.8.6}\\
\vspace*{0.5cm}
-{\small Thu Aug 16 2018 18:36:21}\\
+{\small Thu Aug 16 2018 18:36:28}\\
\end{center}
\end{titlepage}
\clearemptydoublepage


---

Summary of changes:
latex/refman.tex | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)


hooks/post-receive
--
open-mpi/mtt
___
mtt-commits mailing list
mtt-comm...@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/mtt-commits


--
Jeff Squyres
jsquy...@cisco.com

___
mtt-devel mailing list
mtt-devel@lists.open-mpi.org
https://lists.open-mpi.org/mailman/listinfo/mtt-devel

[MTT devel] This list is migrating!

2016-07-19 Thread Jeff Squyres (jsquyres)
Short version
=

The server for this mailing list will be migrating sometime soon (the exact 
timing is not fully predictable).  Three things you need to know:

1. We'll send a "This list is now closed for migration" last message when the 
migration starts
2. We'll send a "This list is now open again" first message when the migration 
completes
3. The list email address will move from @open-mpi.org to @lists.open-mpi.org

More detail
===

The Open MPI hosting infrastructure is slowly moving away from its home of 10+ 
years: our gracious hosts at Indiana University (thank you for all the help and 
support, IU!).  The next pieces to migrate are the Open MPI project mailing 
lists (including this one).

The exact timing of the migration depends on our new hosting provider vendor; 
it's quite difficult to give an exact timeline.  The procedure will generally 
be something like this:

1. Send the final "This list is now closed!" email across this list
2. Shut off all incoming mail to the list
3. Shut down the web pages that allow users to make changes to the list
4. Bundle up all the list data and send it to our new hosting provider
5. Work with the provider to get the new lists online
6. Send a "This list is now open again!" email across the list

As noted above, we're changing the hostnames on the mailing lists to 
@lists.open-mpi.org so that we can de-couple the mailing lists from the rest of 
the web hosting infrastructure.  Please update your addressbook and mail 
filters appropriately.

Webified archives of the mailing lists will continue to be available:

1. Once the migration completes, the existing web archives (under, for example, 
https://www.open-mpi.org/community/lists/users/) will continue to be available, 
but they'll be frozen -- no new messages will be added there.  Specifically: 
links to old posts will continue to work.
2. New web archives for all the lists -- to include all the old posts -- will 
become available elsewhere.  Specifics will be included in the "The list is now 
open again!" mail.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/



[MTT devel] MTT ompi-tests password

2016-05-18 Thread Jeff Squyres (jsquyres)
Folks --

In helping someone get up to speed with MTT yesterday, I updated an MTT sample 
.ini file and accidentally committed the ompiteam-mtt Github password to the 
public repository.  :-(

I have therefore just changed the password for the ompiteam-mtt account.  
Please contact me off-list for the updated password.

Sorry for the inconvenience.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/



Re: [MTT devel] GitHub Issue Cleanup

2016-05-13 Thread Jeff Squyres (jsquyres)
+1

> On May 13, 2016, at 2:27 PM, Ralph Castain  wrote:
> 
> +1 on all these
> 
> Thanks for taking point, Josh!
> 
>> On May 13, 2016, at 11:08 AM, Josh Hursey  wrote:
>> 
>> We are seeing more activity with MTT development, and there is a desire to 
>> push to a formal release at some point in the not-to-distant future. As 
>> such, I think it is time to clean up/out the issues on GitHub. Quite a 
>> number of those issues are feature ideas that we came up with that were 
>> never investigated.
>> 
>> So I propose that we do the following. All of which is open for discussion, 
>> and I can take point on making the changes once we settle on what we want.
>> 
>> Milestones:
>>  1) Mark all existing milestones as completed.
>>  2) Create a v4.0 milestone to track development to the 'first' release (why 
>> not v1.0 - see [A] below)
>>  3) Any issue filed against "Future" will be filed instead against 
>> "ArchivedFuture"
>> 
>> Labels:
>>  1) Create a "work in progress" label - for PRs in progress
>>  2) Create a label for each of the major parts of MTT
>> - "Perl Client"
>> - "Python Client"
>> - "Reporter"
>> - "Database"
>> - "Server"
>>  3) Create a "Wishlist" label where we can label wild enhancement ideas that 
>> we would like, but know we have no time to pursue in the near future. That 
>> way it is easy to get a list of neat things to do for people wanting to jump 
>> in.
>>  4) Create an "Archive" label
>> 
>> Issues:
>>  1) All existing issues get labeled with "Archive" in addition to their 
>> existing labels
>> 
>> 
>> What do folks think? Did I miss anything?
>> 
>> Thanks,
>> Josh
>> 
>> 
>> [A] There was informal v1.0 / v2.0 / v3.0 waypoints in the history. I didn't 
>> want to suggest removing those incase that history is important to us in the 
>> future. However, I'm open to discussing removing them too.
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
>> Searchable archives: 
>> http://www.open-mpi.org/community/lists/mtt-devel/2016/05/0657.php
> 
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/mtt-devel/2016/05/0657.php


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/



Re: [MTT devel] [OMPI devel] mtt-submit, etc.

2015-10-23 Thread Jeff Squyres (jsquyres)
I see the issue in the current code:

1. The current code assumes that if you use the MTT database reporter, you can 
reach the database.  One of the first things it does is ping the server to 
ensure that it's reachable.  The rationale is that you don't want MTT to run 
for a long time and then find out that you can't reach the database to submit 
your results.

2. mtt-relay can certainly be used, but not all sites permit using such a 
thing.  Ditto with an ssh tunnel.

3. Looking at the code, it's probably possible to allow the INI file to specify 
no URL but specify a $debug_filename, and in such cases, ignore some of the 
database-submit code.  E.g.:
   - Skip this block 
https://github.com/open-mpi/mtt/blob/master/lib/MTT/Reporter/MTTDatabase.pm#L178-L203
   - Skip this block 
https://github.com/open-mpi/mtt/blob/master/lib/MTT/Reporter/MTTDatabase.pm#L374-L419
   - Modify this conditional 
https://github.com/open-mpi/mtt/blob/master/lib/MTT/Reporter/MTTDatabase.pm#L424

I'm afraid I don't have the cycles to look deeper into this at the moment, but 
this is where I would start.



> On Oct 23, 2015, at 12:20 AM, George Bosilca  wrote:
> 
> If you are able to connect (assuming ssh) to the nodes that will execute the 
> tests, why can’t you simply use an ssh tunnel to contact the IU server ?
> 
>   George.
> 
>> On Oct 23, 2015, at 00:08 , Ralph Castain  wrote:
>> 
>> I was thinking about this, and I believe it would require a change to the 
>> mtt client to avoid it. I’m working on a new Python-based version of it, and 
>> I’ll make sure to deal with this there.
>> 
>> In the interim, I’ll have to defer to some old, gray Perl guru to update the 
>> current client
>> 
>> 
>>> On Oct 22, 2015, at 9:23 AM, Howard Pritchard  wrote:
>>> 
>>> Hi Folks,
>>> 
>>> I don't seem to have gotten subscribed yet to mtt-users mail list so
>>> forwarding to the dev team.
>>> 
>>> Howard
>>> 
>>> -- Forwarded message --
>>> From: Howard Pritchard 
>>> Date: 2015-10-22 10:18 GMT-06:00
>>> Subject: mtt-submit, etc.
>>> To: mtt-us...@open-mpi.org
>>> 
>>> 
>>> HI Folks,
>>> 
>>> I have the following issue with a cluster I would like to use for 
>>> submitting MTT results
>>> for Open MPI, namely, that the nodes on which I have to submit batch jobs 
>>> to run
>>> the tests don't have external internet connectivity, so if my mtt ini file 
>>> has a IU database reporter
>>> section, the run dies in the "ping the mtt server" test.
>>> 
>>> What I have right now is a two-stage process where I checkout and 
>>> compile/build
>>> Open MPI and the tests on a front end which does have access to the mtt 
>>> server.
>>> This part works and gets reported back to IU database. 
>>> 
>>> I can run the tests using mtt, but have to disable all the mtt server 
>>> reporter stuff.
>>> 
>>> I thought I could use mtt-submit to submit some kind of mttdatabase debug 
>>> file
>>> back to IU once the batch job has completed, but I can't figure out a way
>>> to generate this file without enable the mtt server reporter section in the 
>>> ini file,
>>> and so back to the ping failure issue.
>>> 
>>> Would anyone have suggestions on how to work around this problem?
>>> 
>>> Thanks,
>>> 
>>> Howard
>>> 
>>> 
>>> ___
>>> devel mailing list
>>> de...@open-mpi.org
>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>> Link to this post: 
>>> http://www.open-mpi.org/community/lists/devel/2015/10/18244.php
>> 
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post: 
>> http://www.open-mpi.org/community/lists/devel/2015/10/18249.php
> 
> ___
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/devel/2015/10/18251.php


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/



Re: [MTT devel] [MTT commits] Git: open-mpi/mtt branch master updated. f846c3c2bb57155c2123f8ea4fc6b608a2c37655

2015-02-09 Thread Jeff Squyres (jsquyres)
Mike --

If you're going to change the behavior, please also change the comment.



> On Feb 8, 2015, at 10:11 AM, git...@crest.iu.edu wrote:
> 
> This is an automated email from the git hooks/post-receive script. It was
> generated because a ref change was pushed to the repository containing
> the project "open-mpi/mtt".
> 
> The branch, master has been updated
>   via  f846c3c2bb57155c2123f8ea4fc6b608a2c37655 (commit)
>  from  97b8fae04192bcb6732bc473664b1d0828c481f8 (commit)
> 
> Those revisions listed above that are new to this repository have
> not appeared on any other notification email; so we list those
> revisions in full, below.
> 
> - Log -
> https://github.com/open-mpi/mtt/commit/f846c3c2bb57155c2123f8ea4fc6b608a2c37655
> 
> commit f846c3c2bb57155c2123f8ea4fc6b608a2c37655
> Author: Mike Dubman 
> Date:   Sun Feb 8 17:09:54 2015 +0200
> 
>fix: allow use of relative mtt.ini path from -f /path/to/mtt.ini location
> 
>current behave is to look for include file only in the same dir as 
> supplied mtt.ini file
>allow use relative path from supplied mxm.ini location
> 
> diff --git a/lib/MTT/INI.pm b/lib/MTT/INI.pm
> index 915535d..7a1f129 100644
> --- a/lib/MTT/INI.pm
> +++ b/lib/MTT/INI.pm
> @@ -389,7 +389,11 @@ sub _expand_include_files {
> # If an absolute path is not used, then the file is assumed to be
> # relative to the main --file|f option
> if ($file !~ /^\s*\//) {
> -$file = "$dirname/" . basename($file);
> +if (-f "$dirname/$file") {
> +$file = "$dirname/$file";
> +} else {
> +$file = "$dirname/" . basename($file);
> +}
> }
> 
> if (! -r $file) {
> 
> 
> ---
> 
> Summary of changes:
> lib/MTT/INI.pm | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
> 
> 
> hooks/post-receive
> -- 
> open-mpi/mtt
> ___
> mtt-commits mailing list
> mtt-comm...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-commits


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/



[MTT devel] Migrating Trac wiki and tickets to Github

2014-09-02 Thread Jeff Squyres (jsquyres)
As part of moving the final OMPI SVN repo to Github, we're also converting the 
Trac wiki and tickets.

I have a first attempt at converting the mtt trac wiki to Github's Markdown:

https://github.com/jsquyres/mtt-test/wiki

If this looks good (from a conversion standpoint -- at least some of the 
content needs to be updated for Github), I can move it to the real mtt Github 
wiki.

(ticket conversion is still in the works)

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/



Re: [MTT devel] [MTT svn] GIT: MTT branch master updated. 313f269f46faa4e797ef48791baac659f5cc93ea

2014-07-21 Thread Jeff Squyres (jsquyres)
Good catch; thanks.

On Jul 13, 2014, at 7:35 AM, MPI Team  wrote:

> The branch, master has been updated
>   via  313f269f46faa4e797ef48791baac659f5cc93ea (commit)
>  from  ec7436085d39893e9e87369801b8db44c2e57d14 (commit)
> 
> Those revisions listed above that are new to this repository have
> not appeared on any other notification email; so we list those
> revisions in full, below.
> 
> - Log -
> https://github.com/open-mpi/mtt/commit/313f269f46faa4e797ef48791baac659f5cc93ea
> 
> commit 313f269f46faa4e797ef48791baac659f5cc93ea
> Author: Mike Dubman 
> Date:   Sun Jul 13 14:28:31 2014 +0300
> 
>sub _kill_proc was renamed to _kill_proc_tree but old API was used.
> ---
> lib/MTT/Util.pm | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/MTT/Util.pm b/lib/MTT/Util.pm
> index df2fa21..dd9fbf0 100644
> --- a/lib/MTT/Util.pm
> +++ b/lib/MTT/Util.pm
> @@ -463,7 +463,7 @@ sub term_handler{
>   
> Verbose("###\n");
>   $MTT::Globals::Values->{extra_subject} = " ***Received $signame***";
> 
> - MTT::DoCommand::_kill_proc($MTT::DoCommand::pid);
> + MTT::DoCommand::_kill_proc_tree($MTT::DoCommand::pid);
>   MTT::Reporter::QueueSubmit();
> 
>   if ($trim) {
> 
> ---
> 
> Summary of changes:
> lib/MTT/Util.pm | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> 
> hooks/post-receive
> -- 
> MTT
> ___
> mtt-svn mailing list
> mtt-...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-svn


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/



Re: [MTT devel] MTT: let's use git tags

2014-06-30 Thread Jeff Squyres (jsquyres)
Dave and I finally got to talk about this.

It seems like the simplest/easiest approach is to have a fast-forward-able 
"stable" branch.  I'll set this up and push to github.


On Jun 27, 2014, at 12:11 AM, Christoph Niethammer <nietham...@hlrs.de> wrote:

> +1, for a stable branch which is *fast forwarded* to master when changes are 
> confirmed to work.
> PS: Tags are intended to be static and not moved around in git as Dave says, 
> instead you can sign them using gpg fortifying them even more. ;)
> 
> - Original Message -
> From: "Dave Goodell (dgoodell)" <dgood...@cisco.com>
> To: "Development list for the MPI Testing Tool" <mtt-de...@open-mpi.org>
> Sent: Thursday, June 26, 2014 2:47:35 PM
> Subject: Re: [MTT devel] MTT: let's use git tags
> 
> Published Git tags are *not* movable (by design). You're better off making it 
> a branch that you treat like a tag, if that's your desire. Even then, you 
> might confuse someone who is less familiar with Git in some cases if you move 
> that branch around.
> 
> -Dave
> 
>> On Jun 26, 2014, at 6:06 AM, "Jeff Squyres (jsquyres)" <jsquy...@cisco.com> 
>> wrote:
>> 
>> I've thought about this a little, and I'm still inclined to use the 
>> simple/lazy method of tags on master.  Some random points, in no particular 
>> order:
>> 
>> 1. master should always be for development, IMHO.  If we start using a 
>> multi-branch scheme, then the branches should be for releases, etc.
>> 
>> 2. MTT has always been distributed by VCS; we've never made discrete 
>> distributions (e.g., a tarball).  As such, I'm comfortable labeling it as a 
>> bit "different" than how most other software is delivered -- e.g., using git 
>> tags on master is "good enough".
>> 
>> 3. The level/frequency of MTT development is fairly low; it would be good to 
>> keep the bar as low as possible for amount of work required to deploy a new 
>> feature to the OMPI community for MTT testing.  Meaning: a new feature or 
>> bug fix pops up in MTT every once in a while -- we generally don't have 
>> commits that are being developed and merged to a release series in an 
>> out-of-order fashion.  So doing a few commits for a new feature/bug fix and 
>> then tagging the result is fine/good enough.  If there *are* interleaved 
>> commits of multiple new features/bug fixes, we can simply wait until all are 
>> done before tagging.
>> 
>> 4. I realize this scheme is not as flexible as a release branch (where you 
>> can merge new features/bug fixes out of order), but the level of MTT 
>> development is so low that I'd prefer the slightly-simpler model of just 
>> tagging (vs. merging/etc.).
>> 
>> 5. I'm not sure how using a release branch is less error-prone...?  I 
>> understand git branching is cheap, but if we have a separate branch, then we 
>> either need to remember to cherry-pick every commit we want or we have to 
>> continually merge from master->release_branch.  Seems like more work/steps 
>> to follow, and therefore more error-prone.
>> 
>> 6. The point about not being able to automate getting the latest stable MTT 
>> is a good one.  How about using numerical tags just to delineate our 
>> intended "release" points, but also have a moveable tag, e.g., 
>> "ompi-mtt-testing" that will always point to the latest "release" that we 
>> want the OMPI MTT test community to use?  That way, you can always "git 
>> checkout ompi-mtt-testing" to get the latest/greatest.
>> 
>> (...to that end, I've created/pushed an ompi-mtt-testing tag and pointed to 
>> the same place as v3.0.0)
>> 
>> 
>> 
>>> On Jun 24, 2014, at 8:30 PM, Gilles Gouaillardet 
>>> <gilles.gouaillar...@iferc.org> wrote:
>>> 
>>> +1 for using branches : branch usage is less error prone plus git makes
>>> branching unexpensive.
>>> 
>>> as far as i am concerned, i'd rather have the default master branch is
>>> the for the "stable" version
>>> and have one branch called devel (or dev, or whatever) :
>>> - git clone => get the stable (aka master) branch by default (safe by
>>> default)
>>> - if you use the devel branch, one can only assume you know what you are
>>> doing ...
>>> 
>>> That being said, tags on the master branch is a good practice
>>> 
>>> Cheers,
>>> 
>>> Gilles
>>> 
>>>> On 2014/06/25 2:33, Christoph Niethammer wrote:
>>>> As an alternative

Re: [MTT devel] MTT: let's use git tags

2014-06-26 Thread Jeff Squyres (jsquyres)
I've thought about this a little, and I'm still inclined to use the simple/lazy 
method of tags on master.  Some random points, in no particular order:

1. master should always be for development, IMHO.  If we start using a 
multi-branch scheme, then the branches should be for releases, etc.

2. MTT has always been distributed by VCS; we've never made discrete 
distributions (e.g., a tarball).  As such, I'm comfortable labeling it as a bit 
"different" than how most other software is delivered -- e.g., using git tags 
on master is "good enough".

3. The level/frequency of MTT development is fairly low; it would be good to 
keep the bar as low as possible for amount of work required to deploy a new 
feature to the OMPI community for MTT testing.  Meaning: a new feature or bug 
fix pops up in MTT every once in a while -- we generally don't have commits 
that are being developed and merged to a release series in an out-of-order 
fashion.  So doing a few commits for a new feature/bug fix and then tagging the 
result is fine/good enough.  If there *are* interleaved commits of multiple new 
features/bug fixes, we can simply wait until all are done before tagging.

4. I realize this scheme is not as flexible as a release branch (where you can 
merge new features/bug fixes out of order), but the level of MTT development is 
so low that I'd prefer the slightly-simpler model of just tagging (vs. 
merging/etc.).

5. I'm not sure how using a release branch is less error-prone...?  I 
understand git branching is cheap, but if we have a separate branch, then we 
either need to remember to cherry-pick every commit we want or we have to 
continually merge from master->release_branch.  Seems like more work/steps to 
follow, and therefore more error-prone.

6. The point about not being able to automate getting the latest stable MTT is 
a good one.  How about using numerical tags just to delineate our intended 
"release" points, but also have a moveable tag, e.g., "ompi-mtt-testing" that 
will always point to the latest "release" that we want the OMPI MTT test 
community to use?  That way, you can always "git checkout ompi-mtt-testing" to 
get the latest/greatest.

(...to that end, I've created/pushed an ompi-mtt-testing tag and pointed to the 
same place as v3.0.0)



On Jun 24, 2014, at 8:30 PM, Gilles Gouaillardet 
 wrote:

> +1 for using branches : branch usage is less error prone plus git makes
> branching unexpensive.
> 
> as far as i am concerned, i'd rather have the default master branch is
> the for the "stable" version
> and have one branch called devel (or dev, or whatever) :
> - git clone => get the stable (aka master) branch by default (safe by
> default)
> - if you use the devel branch, one can only assume you know what you are
> doing ...
> 
> That being said, tags on the master branch is a good practice
> 
> Cheers,
> 
> Gilles
> 
> On 2014/06/25 2:33, Christoph Niethammer wrote:
>> As an alternative idea: What about using branches to mark "stable" and 
>> "development"?
>> Tags are for fixed versions and so users will not receive updates unless 
>> they update their update scripts manually?!
>> When "development" is stable just merge into "stable".
> 
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/mtt-devel/2014/06/0636.php


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/



[MTT devel] MTT: let's use git tags

2014-06-24 Thread Jeff Squyres (jsquyres)
The topic came up today that MTT sometimes has bugs, particularly w.r.t. 
ongoing MTT development.

It seems like we should use git tags to let the OMPI/testing community know 
which tag they should be using (vs. HEAD).

To that end, I have created a "v3.0.0" tag that exists before the controversial 
set of commits I pushed the other day -- e12386e.  Assumedly, when we fix 
whatever problem Mellanox is setting with commits beyond e12386e, we can call 
that "v3.0.1", or some such, and ask everyone to move up to it.

So those who need stability should stick back at tags, and those who want to 
help with development can be at the HEAD.

How does that sound?

If that sounds ok, I'll ask the OMPI test community to git checkout v3.0.0.  
And in the future, we'll ask the OMPI test community to update to the next 
relevant tag, etc.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/



Re: [MTT devel] [MTT svn] GIT: MTT branch master updated. 016088f2a0831b32ab5fd6f60f4cabe67e92e594

2014-06-23 Thread Jeff Squyres (jsquyres)
Ok, just got in to Chicago from my flight and am back online.

Mike: you are still not providing very much information.  :-\

Your first mails make it seem like MTT is continuing to run, but leaving 
"launchers" (assumedly mpirun processes) still running, but they have no 
children.  Which would be very weird for mpirun to do, if it has no children 
left.  This could be both an MTT and an ORTE bug, in this case.

But your last mail seems to imply that MTT is hanging indefinitely.

Can you please provide a clear, precise description of what is happening?

FWIW: Yes, we are killing the parent first now, to give mpirun a chance to 
cleanup / tell remote orteds to die / kill children processes / etc.  Killing 
the children first both doesn't test the common case of how people kill MPI 
processes (i.e., they kill mpirun), and it also doesn't allow mpirun to tell 
remote processes to die.

Do you run with --verbose output?  MTT should output messages like "*** Killing 
mpirun with SIGTERM", and the like.  Do you see timeout messages at all?  I.e., 
is MTT not entering the timeout code at all?

...etc.



On Jun 23, 2014, at 12:16 PM, Dave Goodell (dgoodell)  
wrote:

> On Jun 23, 2014, at 8:48 AM, Mike Dubman  wrote:
> 
>> btw, i think now, when parent process is killed before child, OS makes child 
>> as "" which stick around for good.
> 
> The grandparent should inherit the child.  If the grandparent then does not 
> wait(2) on the child, then the child will remain a zombie / defunct.  So in 
> our specific case, this behavior will depend on what the parent process of 
> mpirun is and whether it is waiting on child processes appropriately.
> 
> -Dave
> 
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
> Link to this post: 
> http://www.open-mpi.org/community/lists/mtt-devel/2014/06/0633.php


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/



Re: [MTT devel] [MTT svn] GIT: MTT branch master updated. 016088f2a0831b32ab5fd6f60f4cabe67e92e594

2014-06-23 Thread Jeff Squyres (jsquyres)
On Jun 23, 2014, at 7:47 AM, Mike Dubman  wrote:

> after patch, it killed child processes but kept mpirun ... itself.

What does that mean -- are you saying that mpirun is still running?  Was mpirun 
sent a signal at all?  What kind of messages are being displayed?  ...etc.

The commits fix important bugs for me and others.  Clearly, there's still 
something not right.  And of course I'm willing to track it down.  But I can't 
help you if you just say "it doesn't work."

> before that patch - all processes were killed (and you are right, "mpirun 
> died right at the end of the timeout" was reported)

...which led to many months of misleading ORTE debugging, BTW.  :-\  That's why 
this commit was introduced into MTT -- in the quest of finally fixing both the 
mysterious ORTE hangs and the erroneous timeouts/"mpirun died right at the end" 
messages.

> but at least it left the cluster in the clean state w/o leftovers.
> now many "orphan" launchers  are alive from previous invocations.

Does "launchers" = mpirun?

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/



Re: [MTT devel] [MTT svn] GIT: MTT branch master updated. 016088f2a0831b32ab5fd6f60f4cabe67e92e594

2014-06-23 Thread Jeff Squyres (jsquyres)
There was actually quite a bit of testing before this was committed.  This 
commit resolved a lot of hangs across multiple organizations.

Can you be more specific as to what is happening?

The prior code was killing child processes before mpirun itself, for example, 
which has led MTT to erroneously report that mpirun died right at the end of 
the timeout without being killed.  This has been ongoing for many months, at a 
minimum.




On Jun 23, 2014, at 4:37 AM, Mike Dubman  wrote:

> this commit does more harm then good.
> we experience following:
> 
> - some child processes still running after timeout and mtt killed the job.
> 
> before this commit - it worked fine.
> please revert and test more.
>  
> 
> 
> On Sat, Jun 21, 2014 at 3:30 PM, MPI Team  wrote:
> The branch, master has been updated
>via  016088f2a0831b32ab5fd6f60f4cabe67e92e594 (commit)
>via  7fb4c6a4c9d71be127ea53bd463178510577f71f (commit)
>via  381ba177d835a54c3197d846f5a4edfc314efe27 (commit)
>via  cfdd29de2012eeb7592706f00dd07a52dd48cf6b (commit)
>via  940030ca20eb1eaf256e898b83866c1cb83aca5c (commit)
>   from  c99ed7c7b159a2cab58a251bd7c0dad8972ff901 (commit)
> 
> Those revisions listed above that are new to this repository have
> not appeared on any other notification email; so we list those
> revisions in full, below.
> 
> - Log -
> https://github.com/open-mpi/mtt/commit/016088f2a0831b32ab5fd6f60f4cabe67e92e594
> 
> commit 016088f2a0831b32ab5fd6f60f4cabe67e92e594
> Author: Jeff Squyres 
> Date:   Sat Jun 21 04:58:45 2014 -0700
> 
> DoCommand: several fixes to kill_proc logic
> 
> 1. Fix the kill(0, $pid) test to see if the process was still alive.
> 
> 2. Rename _kill_proc() to _kill_proc_tree() to indicate that it's
> really killing not only the PID in question, but also all of its
> descendants.
> 
> 3. In _kill_proc_tree(), change the order to kill the main PID first,
> and ''then'' kill all the descendants.
> 
> The main use case is when killing mpirun: if we kill mpirun's
> descendants ''first'', mpirun will detect its childrens' deaths and
> then cleanup and exit.  Later, when MTT finally gets around to killing
> mpirun, MTT will detect that mpirun is already dead and therefore emit
> a confusing "mpirun died right at end of timeout" message.  This is
> misleading at best; it doesn't indicate what actually happened.
> 
> However, if we kill mpirun first, it will take care of killing all of
> its descendants.  MTT will therefore emit the right messages about
> killing mpirun.  MTT will then redundantly try to kill a bunch of
> now-nonexistent descendant processes of mpirun, but that's ok/safe.
> We actually ''want'' this try-to-kill-mpirun's-descendants behavior to
> handle the case when mpirun is misbehaving / not cleaning up its
> descendants.
> 
> 4. DoCommand() is used for more than launching mpirun, so pass down
> $argv0 so that we can print the actual command name that is being
> killed in various Verbose/Debug messages, not the hard-coded "mpirun"
> string (which, in practice, was probably almost always correct, but
> still...).
> ---
>  lib/MTT/DoCommand.pm | 78 
> 
>  1 file changed, 55 insertions(+), 23 deletions(-)
> 
> diff --git a/lib/MTT/DoCommand.pm b/lib/MTT/DoCommand.pm
> index 02cdb94..646ca31 100644
> --- a/lib/MTT/DoCommand.pm
> +++ b/lib/MTT/DoCommand.pm
> @@ -2,7 +2,7 @@
>  #
>  # Copyright (c) 2005-2006 The Trustees of Indiana University.
>  # All rights reserved.
> -# Copyright (c) 2006-2013 Cisco Systems, Inc.  All rights reserved.
> +# Copyright (c) 2006-2014 Cisco Systems, Inc.  All rights reserved.
>  # Copyright (c) 2007-2008 Sun Microsystems, Inc.  All rights reserved.
>  # Copyright (c) 2007-2012 High Performance Computing Center Stuttgart,
>  # University of Stuttgart.  All rights reserved.
> @@ -57,23 +57,27 @@ sub DoCommand {
>  ($time_arg, $no_execute) = @_;
>  }
> 
> +# This function is called for killing both mpirun and each of its
> +# descendants.  We really only want to see verbose output for when we
> +# kill mpirun itself, so only show output when the caller provides us
> +# with a $argv0 value.
>  sub _kill_proc_one {
> -my ($pid) = @_;
> +my ($pid, $argv0) = @_;
> 
>  # How long to wait after each kill()
>  my $wait_time = 5;
> 
>  # See if the proc is alive first
> -my $kid;
> -kill(0, $pid);
> -$kid = waitpid($pid, WNOHANG);
> -return "mpirun died right at end of timeout (MTT did not have to kill 
> it)"
> -if (-1 == $kid);
> +my $num_alive = kill(0, $pid);
> +return "$argv0 died right at end of timeout (MTT did not have to kill 
> it)"
> +if (0 == 

Re: [MTT devel] Converted to git

2014-04-17 Thread Jeff Squyres (jsquyres)
I assume this means that no one found any problems or has any changes.

I'll be moving this to its permanent home on github sometime soon and making 
the MTT SVN be read-only.  Trac will be migrating to be git-based soon as well.

Please do not use the MTT trac until further notice.  Thanks!


On Apr 16, 2014, at 3:40 PM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> wrote:

> BTW, I used the following SVN<-->email addresses mapping for creating the git 
> commits.  Let me know if you want something different:
> 
> adkulkar = Abhishek Kulkarni <adkul...@cs.indiana.edu>
> afriedle = Andrew Friedley <afrie...@osl.iu.edu>
> brbarret = Brian Barrett <brbar...@open-mpi.org>
> cyeoh = Chris Yeoh <cy...@au1.ibm.com>
> em162155 = Ethan Mallove <ethan.mall...@oracle.com>
> emallove = Ethan Mallove <ethan.mall...@oracle.com>
> eugene = Eugene Loh <eugene@oracle.com>
> hpcstork = Sven Stork <sven.st...@open-mpi.org>
> jjhursey = Josh Hursey <jjhur...@open-mpi.org>
> jsquyres = Jeff Squyres <jsquy...@cisco.com>
> miked = Mike Dubman <mi...@mellanox.com>
> pasha = Pavel Shamis <sham...@ornl.gov>
> rusraink = Rainer Keller <rainer.kel...@hft-stuttgart.de>
> shiqing = Shiqing Fan <f...@hlrs.de>
> timattox = Tim Mattox <timat...@open-mpi.org>
> 
> 
> On Apr 16, 2014, at 3:37 PM, "Jeff Squyres (jsquyres)" <jsquy...@cisco.com> 
> wrote:
> 
>> I have done a TRIAL conversion to git and pushed it to a demo repo at 
>> github.  Please examine it and let me know if you see any problems:
>> 
>>   https://github.com/jsquyres/mtt-test
>> 
>> Note that we converted references to "rXYZ" in log messages -- see 
>> https://github.com/jsquyres/mtt-test/commit/ebb98c67677b02fa00064f8b1ae0d40941c305cd
>>  for an example.
>> 
>> -- 
>> Jeff Squyres
>> jsquy...@cisco.com
>> For corporate legal information go to: 
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>> 
>> ___
>> mtt-devel mailing list
>> mtt-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
> 
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/



Re: [MTT devel] Converted to git

2014-04-16 Thread Jeff Squyres (jsquyres)
BTW, I used the following SVN<-->email addresses mapping for creating the git 
commits.  Let me know if you want something different:

adkulkar = Abhishek Kulkarni <adkul...@cs.indiana.edu>
afriedle = Andrew Friedley <afrie...@osl.iu.edu>
brbarret = Brian Barrett <brbar...@open-mpi.org>
cyeoh = Chris Yeoh <cy...@au1.ibm.com>
em162155 = Ethan Mallove <ethan.mall...@oracle.com>
emallove = Ethan Mallove <ethan.mall...@oracle.com>
eugene = Eugene Loh <eugene@oracle.com>
hpcstork = Sven Stork <sven.st...@open-mpi.org>
jjhursey = Josh Hursey <jjhur...@open-mpi.org>
jsquyres = Jeff Squyres <jsquy...@cisco.com>
miked = Mike Dubman <mi...@mellanox.com>
pasha = Pavel Shamis <sham...@ornl.gov>
rusraink = Rainer Keller <rainer.kel...@hft-stuttgart.de>
shiqing = Shiqing Fan <f...@hlrs.de>
timattox = Tim Mattox <timat...@open-mpi.org>


On Apr 16, 2014, at 3:37 PM, "Jeff Squyres (jsquyres)" <jsquy...@cisco.com> 
wrote:

> I have done a TRIAL conversion to git and pushed it to a demo repo at github. 
>  Please examine it and let me know if you see any problems:
> 
>https://github.com/jsquyres/mtt-test
> 
> Note that we converted references to "rXYZ" in log messages -- see 
> https://github.com/jsquyres/mtt-test/commit/ebb98c67677b02fa00064f8b1ae0d40941c305cd
>  for an example.
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/



[MTT devel] Converted to git

2014-04-16 Thread Jeff Squyres (jsquyres)
I have done a TRIAL conversion to git and pushed it to a demo repo at github.  
Please examine it and let me know if you see any problems:

https://github.com/jsquyres/mtt-test

Note that we converted references to "rXYZ" in log messages -- see 
https://github.com/jsquyres/mtt-test/commit/ebb98c67677b02fa00064f8b1ae0d40941c305cd
 for an example.

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/



Re: [MTT devel] [MTT svn] svn:mtt-svn r1637 - trunk/lib/MTT/Values/Functions/MPI

2014-04-07 Thread Jeff Squyres (jsquyres)
On Apr 7, 2014, at 6:39 PM, Mike Dubman  wrote:

> somehow we run it with both, --verbose not enough to understand the problem 
> and --debug is too much.
> 
> maybe --trace is here to rescue?

It won't really solve the problem; it'll just create another level of argument 
about where a given message should go (now there will be 3 levels instead of 
2... eventually there will be 4, and then 5, and then ...).

Do you really need to run with --debug all the time?  I.e., do you have so many 
problems with MTT itself that you need to run with --debug?

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/



Re: [MTT devel] [MTT svn] svn:mtt-svn r1637 - trunk/lib/MTT/Values/Functions/MPI

2014-04-07 Thread Jeff Squyres (jsquyres)
Yes.

The intent is that --debug is *very* verbose, and is generally only useful 
when something goes wrong.

I run Cisco's automated MTT with only --verbose.



On Apr 7, 2014, at 6:35 PM, Mike Dubman <mi...@dev.mellanox.co.il> wrote:

> ohh.. it is just flooding the log with same data for every test launch.
> 
> maybe we should have verbose level in mtt?
> 
> 
> On Mon, Apr 7, 2014 at 6:30 PM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> 
> wrote:
> Mike --
> 
> Why did you comment these out?  By definition, --debug output should be a LOT 
> of output.
> 
> 
> On Apr 5, 2014, at 7:27 PM, <svn-commit-mai...@open-mpi.org> wrote:
> 
> > Author: miked (Mike Dubman)
> > Date: 2014-04-05 19:27:28 EDT (Sat, 05 Apr 2014)
> > New Revision: 1637
> > URL: https://svn.open-mpi.org/trac/mtt/changeset/1637
> >
> > Log:
> > silence print
> >
> > Text files modified:
> >   trunk/lib/MTT/Values/Functions/MPI/OMPI.pm | 4 ++--
> >   1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > Modified: trunk/lib/MTT/Values/Functions/MPI/OMPI.pm
> > ==
> > --- trunk/lib/MTT/Values/Functions/MPI/OMPI.pmMon Mar 17 14:14:47 
> > 2014(r1636)
> > +++ trunk/lib/MTT/Values/Functions/MPI/OMPI.pm2014-04-05 19:27:28 
> > EDT (Sat, 05 Apr 2014)  (r1637)
> > @@ -331,7 +331,7 @@
> >
> > # Check the environment for OMPI_MCA_* values
> > foreach my $e (keys(%ENV)) {
> > -Debug("Functions::MPI::OMPI: Checking env key: $e\n");
> > +#Debug("Functions::MPI::OMPI: Checking env key: $e\n");
> > if ($e =~ m/^OMPI_MCA_(\S+)/) {
> > my $v = $ENV{"OMPI_MCA_$1"};
> > push(@params, "--env-mca $1 $v");
> > @@ -339,7 +339,7 @@
> > }
> >
> > $str = join(' ', @params);
> > -Debug("Functions::MPI::OMPI: Returning MCA params $str\n");
> > +#Debug("Functions::MPI::OMPI: Returning MCA params $str\n");
> > $str;
> > }
> >
> > ___
> > mtt-svn mailing list
> > mtt-...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/mtt-svn
> 
> 
> --
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
> 
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/



Re: [MTT devel] [MTT svn] svn:mtt-svn r1637 - trunk/lib/MTT/Values/Functions/MPI

2014-04-07 Thread Jeff Squyres (jsquyres)
Mike --

Why did you comment these out?  By definition, --debug output should be a LOT 
of output.


On Apr 5, 2014, at 7:27 PM,  wrote:

> Author: miked (Mike Dubman)
> Date: 2014-04-05 19:27:28 EDT (Sat, 05 Apr 2014)
> New Revision: 1637
> URL: https://svn.open-mpi.org/trac/mtt/changeset/1637
> 
> Log:
> silence print
> 
> Text files modified: 
>   trunk/lib/MTT/Values/Functions/MPI/OMPI.pm | 4 ++-- 
>
>   1 files changed, 2 insertions(+), 2 deletions(-)
> 
> Modified: trunk/lib/MTT/Values/Functions/MPI/OMPI.pm
> ==
> --- trunk/lib/MTT/Values/Functions/MPI/OMPI.pmMon Mar 17 14:14:47 
> 2014(r1636)
> +++ trunk/lib/MTT/Values/Functions/MPI/OMPI.pm2014-04-05 19:27:28 EDT 
> (Sat, 05 Apr 2014)  (r1637)
> @@ -331,7 +331,7 @@
> 
> # Check the environment for OMPI_MCA_* values
> foreach my $e (keys(%ENV)) {
> -Debug("Functions::MPI::OMPI: Checking env key: $e\n");
> +#Debug("Functions::MPI::OMPI: Checking env key: $e\n");
> if ($e =~ m/^OMPI_MCA_(\S+)/) {
> my $v = $ENV{"OMPI_MCA_$1"};
> push(@params, "--env-mca $1 $v");
> @@ -339,7 +339,7 @@
> }
> 
> $str = join(' ', @params);
> -Debug("Functions::MPI::OMPI: Returning MCA params $str\n");
> +#Debug("Functions::MPI::OMPI: Returning MCA params $str\n");
> $str;
> }
> 
> ___
> mtt-svn mailing list
> mtt-...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-svn


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/



[MTT devel] Migrating www.open-mpi.org

2013-08-05 Thread Jeff Squyres (jsquyres)
All --

Our hosting provider will be migrating 
www.open-mpi.org to a new machine on Wednesday.  See 
message below for details.


Begin forwarded message:

From: DongInn Kim >
Subject: Migrating www.open-mpi.org from milliways to 
lion
List-Post: mtt-devel@lists.open-mpi.org
Date: August 5, 2013 11:53:38 AM PDT

Dear Open MPI developers and users,

We are planning to move all the services under 
www.open-mpi.org to the new server on Wednesday, Aug 
7th, 2013.
This migration may need some outage time of web services (e.g., 
http://www.open-mpi.org) and mailing list services 
(e.g., us...@open-mpi.org, 
de...@open-mpi.org, …).

The migration schedule is following:
- Date: Wednesday, Aug 7th, 2013
- Time:
6:00am-8:00am Pacific US time
7:00am-9:00am Mountain US time
8:00am-10:00am Central US time
9:00am-11:00am Eastern US time
1:00pm-3:00pm GMT

The following services would not be available during the migration.

- Web services (e.g., www.open-mpi.org)
- mailing lists:
  ad...@open-mpi.org
  announce
  bugs
  devel
  devel-core
  docs
  ft
  hwloc-announce
  hwloc-bugs
  hwloc-devel
  hwloc-svn
  hwloc-users
  llamas
  mtt-announce
  mtt-bugs
  mtt-devel
  mtt-devel-core
  mtt-results
  mtt-svn
  mtt-users
  ompi-user-docs-bugs
  ompi-user-docs-svn
  svn
  svn-docs
  svn-docs-full
  svn-full
  svn-private
  svn-private-full
  users
- Mail archives
  http://www.open-mpi.org/community/lists/
- Mercurial mirror
  Will disappear (it has long-since moved out to Bitbucket)

I hope that we will not lose any mails sent to the above mailing lists even 
during the migration but it would be really appreciated if you hold up sending 
emails and svn commit until the migration is done.

Please let me know if you have any questions or issues about this migration.

Regards,

--
- DongInn
---
CREST System administrator
Indiana University
Bloomington, IN


--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/



Re: [MTT devel] fix zombie commit

2013-02-26 Thread Jeff Squyres (jsquyres)
On Feb 26, 2013, at 2:11 AM, Mike Dubman <mi...@dev.mellanox.co.il> wrote:

> On Mon, Feb 25, 2013 at 6:24 PM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> 
> wrote:
> >Looking at the code, you're checking for zombie status before MTT kills the 
> >proc.  Am I reading that right?
> I don`t think the order matters, if process is not Zombie yet and about to be 
> killed by MTT later - it is a good flow.
> If process is already Zombie - mtt will not be able to kill it anyway and and 
> can stop waiting and switch to the new task.

No, the _kill_proc() routine does both a kill() and a waitpid().  The waitpid() 
should reap the zombie.

I.e., if the process has died, MTT simply just hasn't reaped it yet.  Hence, 
it's a zombie.

> >If so, then it could well be that the process has exited but not yet been 
> >reaped (because _kill_proc() hasn't been invoked yet).  If this is the case, 
> >is the real cause of the problem that >the OUTread and ERRread aren't being 
> >closed when the child process exits, and therefore we keep looping looking 
> >for new output from them?
> yep, sounds like it can be the cause, need to look into this code.

Ok.  It would be interesting to see if the process dies, but:

1) MTT is still blocking in select() (i.e., OUTread and OUTerr aren't returning 
0 from sysread upon process death)

2) $done is somehow not getting set to 0, and therefore MTT is still looping 
until the timeout expires

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/




Re: [MTT devel] fix zombie commit

2013-02-25 Thread Jeff Squyres (jsquyres)
On Feb 24, 2013, at 6:59 AM, Mike Dubman  wrote:

> What protection do you mean? Check that /proc/pid/status exists? It is done 
> in Grep()

Ah, excellent -- I hadn't noticed that.

> We observe that process which was launched by mtt and hangs (mtt detect 
> timeout and starts do_command procedure), later enters into "defunct" state.

Looking at the code, you're checking for zombie status before MTT kills the 
proc.  Am I reading that right?

If so, then it could well be that the process has exited but not yet been 
reaped (because _kill_proc() hasn't been invoked yet).  If this is the case, is 
the real cause of the problem that the OUTread and ERRread aren't being closed 
when the child process exits, and therefore we keep looping looking for new 
output from them?

-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/




[MTT devel] fix zombie commit

2013-02-24 Thread Jeff Squyres (jsquyres)
Mike --

Please protect this code better; MTT is also run on Solaris and OS X.

Also, can you describe more fully the case where zombies are being left behind 
by MTT?


On Feb 24, 2013, at 1:44 AM,  wrote:

> Author: miked (Mike Dubman)
> Date: 2013-02-24 01:44:31 EST (Sun, 24 Feb 2013)
> New Revision: 1589
> URL: https://svn.open-mpi.org/trac/mtt/changeset/1589
> 
> Log:
> * fix: fork leaves zombie processes sometimes. temp fix: detect zombie and 
> proceed with tests.
> 
> Text files modified: 
>   trunk/lib/MTT/DoCommand.pm | 6 ++  
>   1 files changed, 6 insertions(+), 0 deletions(-)
> 
> Modified: trunk/lib/MTT/DoCommand.pm
> ==
> --- trunk/lib/MTT/DoCommand.pmWed Feb 20 12:41:12 2013(r1588)
> +++ trunk/lib/MTT/DoCommand.pm2013-02-24 01:44:31 EST (Sun, 24 Feb 
> 2013)  (r1589)
> @@ -641,6 +641,12 @@
> if (!$pid_exists) {
> Verbose("--> Process completed somehow at " . time() . ", 
> proceeding with tests\n");
> $resume_tests++;
> +} else {
> +my $matches = MTT::Files::Grep("zombie", "/proc/$pid/status");
> +if (@$matches) {
> +Verbose("--> Process become Zombie at " . time() . ", 
> proceeding with tests\n");
> +$resume_tests++;
> +}
> }
> # Remove the timeout sentinel file, if a timeout notify timeout value 
> is set
> if (defined($end_time) and time() > $end_time) {
> ___
> mtt-svn mailing list
> mtt-...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-svn


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/




Re: [MTT devel] [MTT svn] svn:mtt-svn r1575 - trunk/lib/MTT/Reporter

2013-01-15 Thread Jeff Squyres (jsquyres)
Wow!  Icky.  That should be reported upstream.


On Jan 15, 2013, at 1:28 PM, Mike Dubman <mi...@dev.mellanox.co.il>
 wrote:

> there is a die"" in the MongoDB.connect :(
> 
> On Mon, Jan 14, 2013 at 4:47 PM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> 
> wrote:
> That's weird.  Why would an "eval" fix this situation?
> 
> 
> On Jan 14, 2013, at 8:15 AM, svn-commit-mai...@open-mpi.org wrote:
> 
> > Author: miked (Mike Dubman)
> > Date: 2013-01-14 08:15:54 EST (Mon, 14 Jan 2013)
> > New Revision: 1575
> > URL: https://svn.open-mpi.org/trac/mtt/changeset/1575
> >
> > Log:
> > fixes #1696
> >
> > Text files modified:
> >   trunk/lib/MTT/Reporter/MTTMongodb.pm | 2 +-
> >   1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > Modified: trunk/lib/MTT/Reporter/MTTMongodb.pm
> > ==
> > --- trunk/lib/MTT/Reporter/MTTMongodb.pm  Fri Jan  4 14:39:57 2013  
> >   (r1574)
> > +++ trunk/lib/MTT/Reporter/MTTMongodb.pm  2013-01-14 08:15:54 EST (Mon, 
> > 14 Jan 2013)  (r1575)
> > @@ -117,7 +117,7 @@
> >
> >   if($enable_mongo == 1)
> >   {
> > - eval "$conn = MongoDB::Connection->new(host => $url);";
> > + $conn = MongoDB::Connection->new(host => $url);
> >   if(defined($conn))
> >   {
> >   $db = $conn->mlnx_mtt;
> > ___
> > mtt-svn mailing list
> > mtt-...@open-mpi.org
> > http://www.open-mpi.org/mailman/listinfo.cgi/mtt-svn
> 
> 
> --
> Jeff Squyres
> jsquy...@cisco.com
> For corporate legal information go to: 
> http://www.cisco.com/web/about/doing_business/legal/cri/
> 
> 
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel
> 
> ___
> mtt-devel mailing list
> mtt-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/mtt-devel


-- 
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to: 
http://www.cisco.com/web/about/doing_business/legal/cri/




[MTT devel] Broken MTT trunk

2012-03-29 Thread Jeff Squyres (jsquyres)
It looks like some of my recent commits have broken the trunk.  I'll be looking 
at this today. 

But it might be safest for those running off the trunk to update to a few days 
ago. 

Sent from my phone. No type good. 


Re: [MTT devel] MTToGDS

2010-03-04 Thread Jeff Squyres (jsquyres)
Ok. I'll try to look at this as well - but no promises about when I can do 
so... 

-jms 
Sent from my PDA. No type good.



From: Igor Ivanov <igor.iva...@itseez.com> 
To: Igor Ivanov <igor.iva...@itseez.com> 
Cc: b...@argus-cv.com <b...@argus-cv.com>; Igor Ivanov 
<igor.iva...@argus-cv.com>; Development list for the MPI Testing Tool 
<mtt-de...@open-mpi.org>; mtt-devel-boun...@open-mpi.org 
<mtt-devel-boun...@open-mpi.org>; Mike Dubman <mi...@voltaire.com>; Jeff 
Squyres (jsquyres) 
Sent: Thu Mar 04 01:31:16 2010
Subject: Re: [MTT devel] MTToGDS 




Igor Ivanov wrote: 

I considered possibility to use cookie when issue was found out. But 
looking google documentation I could not understand if it solved this issue. So 
it require additional investigation that I do not have now. I will look in this 
way closer but current quick solutions were suggested in mail.
Now we have information about issue and know ways to workaround them.

Igor

Jeff Squyres wrote: 

Yoinks.

Alternatively, doesn't a Google login return a cookie of some 
flavor that is valid for a long period of time (somewhere between 1 day and 2 
weeks)?  Can't we keep/cache that cookie down in the MTT client and use it for 
subsequent data submissions until the cookie expires and we have to login again?


On Feb 27, 2010, at 8:30 AM, Igor Ivanov wrote:

  

Description:
Issue arises during submitting data frequently. We can 
get failure during data submitting with authentication error.

Reason:
Google allows a failure response on The ClientLogin 
authorization process with a CAPTCHA challenge means that Google has decided, 
for whatever reason, that additional security measures should be taken. This 
response is accompanied by a CAPTCHA image URL and a token representing the 
specific CAPTCHA challenge.
I do not see way to organize customer input in this 
case.

Detail information can be found at:

http://code.google.com/intl/en-EN/apis/accounts/docs/AuthForInstalledApps.html

Possible solutions:
1. catch error condition on server side and return 
status 503: 'Service Unavailable';
In this case client can organize processing of this 
failure (it is possible that sleeping for some time could help)
2. catch error condition on server side and accept 
authentication by correct username only w/o real verification;
3. rollback to previous scheme;


Igor

Igor Ivanov wrote:


Hi Jeff,

I am sending patch that enable google account 
approach to submit data to MTT GDS.
It also has the fix to a bug in displaying 
table as respond to bquery.pl --view (It has not been committed yet to MTT 
trunk).

As for question relating "how does one develop 
..." that source information can be found at following location as: 
http://svn.open-mpi.org/svn/mtt/trunk/docs/gds/VBench_GDS_Setup.doc.
In case you make a resolve to accept patch I am 
sending next steps should be done:

1. update application on server side using 
instruction in VBench_GDS_Setup.doc (topic 4 "Installation")
example: appcfg.py update /
2. change version on 
https://appengine.google.com/deployment?_id=open-mpi-mtt_id=1.337140739868725607
 from 1 to 2 (make default)
note: after this operation all users that 
attempt to submit data using previous scheme of authentication will get failure 
respond.
3. go to open-mpi-mtt and add new users with 
google account


Regards,
Igor

Jeff Squyres wrote:
  

Great -- many thanks!

  

Re: [MTT devel] MTToGDS

2010-03-04 Thread Jeff Squyres (jsquyres)
Fair enough (the appspot is quit limited to admin). 

But the next time we edit it, if we could add some kind of printf about "you 
are signed in with a google account that does not have access to this portion 
of the app spot; please re-login as an authorized user" or something simple 
like that, that would be great. 

That's all I was asking about - not developing more capabilities of the admin 
side of the appspot. 

-jms 
Sent from my PDA. No type good.



From: Igor Ivanov <igor.iva...@itseez.com> 
To: Igor Ivanov <igor.iva...@itseez.com> 
Cc: b...@argus-cv.com <b...@argus-cv.com>; Igor Ivanov 
<igor.iva...@argus-cv.com>; Development list for the MPI Testing Tool 
<mtt-de...@open-mpi.org>; yift...@voltaire.com <yift...@voltaire.com>; Mike 
Dubman <mi...@voltaire.com>; Jeff Squyres (jsquyres) 
Sent: Thu Mar 04 01:30:56 2010
Subject: Re: [MTT devel] MTToGDS 




Igor Ivanov wrote: 

Hi Jeff,

Look  at my comments below.

Note: be aware that my mail has been changed to itseez.com domain.

Igor

Jeff Squyres wrote: 

On Feb 16, 2010, at 10:19 AM, Igor Ivanov wrote:

  

I am sending patch that enable google account approach 
to submit data to MTT GDS.
It also has the fix to a bug in displaying table as 
respond to bquery.pl --view (It has not been committed yet to MTT trunk).



Thanks guys!  And sorry for my long lack of response - I was 
working in a window of availability for MTT stuff before, and then that window 
closed and I got sucked into other high priority things.  I have another small 
window of availability for MTT now...

It looks like Mike D. committed this stuff to SVN already, 
right?  If so, great!

  

As for question relating "how does one develop ..." 
that source information can be found at following location as: 
http://svn.open-mpi.org/svn/mtt/trunk/docs/gds/VBench_GDS_Setup.doc.



Ok, I'll dig into that.

One thing that is quite confusing is the sign in to 
http://open-mpi-mtt.appspot.com/.  When you go there, you get a "Sign in or 
register" link.  You click that and get to a Google Accounts login.  I used 
openmpi.ci...@gmail.com and its associated password, but then I'm bounced back 
to the "Sign in or register" link.

Only when I login as open...@gmail.com do I actually get beyond 
the "Sign in or register" link.

Does this mean that openmpi.ci...@gmail.com does not have login 
privlidges on the open-mpi-mtt appspot?  If so, can we add a better error 
message than this?  It's very confusing -- because you *are* apparently signing 
in to a google account properly, but then you just get the "Sign in or 
register" link again.
  

[ii] As I mentioned in previous mails current form of web-site suits 
administrating purpose mostly (to fit full multiuser access it should be 
provided additional
operations). So I knowingly limited admission for administrator only as 
"openmpi" to avoid additional questions in multiuser usage. 
  

  

In case you make a resolve to accept patch I am sending 
next steps should be done:

1. update application on server side using instruction 
in VBench_GDS_Setup.doc (topic 4 "Installation")
example: appcfg.py update /
2. change version on 
https://appengine.google.com/deployment?_id=open-mpi-mtt_id=1.337140739868725607
 from 1 to 2 (make default)
note: after this operation all users that attempt to 
submit data using previous scheme of authentication will get failure respond.
3. go to open-mpi-mtt and add new users with google 
account



It looks like this was all done already -- probably because I 
took so long to reply.

Thanks!

  



__ Information from ESET NOD32 Antivirus, version of virus 
signature database 4913 (20100303) __

The message was checked by ESET NOD32 Antivirus.

http://www.esetnod32.ru


__ Information from ESET NOD32 Antivirus, version of virus 
signature database 4913 (20100303) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset

Re: [MTT devel] OTF testing tool

2009-07-10 Thread Jeff Squyres (jsquyres)
That sounds yummy - andreas can you help out with how to invoke the otf tool?

-jms
Sent from my PDA.  No type good.

- Original Message -
From: mtt-devel-boun...@open-mpi.org 
To: Development list for the MPI Testing Tool 
Cc: Andreas Kn?pfer 
Sent: Fri Jul 10 14:27:53 2009
Subject: Re: [MTT devel] OTF testing tool

On Fri, Jul/10/2009 09:51:35AM, Jeff Squyres wrote:
> Ethan - have you seen this?
>
> https://svn.open-mpi.org/trac/ompi/ticket/1967
>
> Do you have any cycles to try to integrate it into MTT?  I was slammed this 
> past week and am out on vacation last week.  But I would very much like to 
> get this into regular MTT testing...

I think there's a simpler way to do this without having to create
another Analyze/Correctness_VampirTrace.pm module. E.g., I have some
vampirtrace stuff in my INI that look like this:

  [MPI details: Open MPI]
  ...
  exec:vampir_trace = _executable() --host _hosts() --prefix 
_prefix() _argv()
  ...

  [Test get: trivial]
  module = Trivial

  [Test build: trivial-VampirTrace]
  test_get = trivial
  module = Trivial

  # Use the VampirTrace wrapper compilers, instead of 
  # the plain vanilla MPI wrappers
  trivial_tests_mpicc  = mpicc-vt
  trivial_tests_mpicxx = mpicxx-vt
  trivial_tests_mpif77 = mpif77-vt
  trivial_tests_mpif90 = mpif90-vt

  [Test run: trivial-VampirTrace]
  test_build = trivial-vampirtrace
  pass = ((_wexitstatus(), 0), _trace_files_exist())

  module = Simple
  specify_module = Simple
  simple_only:tests = _executables(".")
  simple_only_if_exec_exists = 1
  mpi_details_exec = vampir_trace

The above just gets and builds Trivial tests. Then instead of running
them via "mpirun", MTT executes them directly to create the trace
files:

  $ c_hello --host foo,bar --prefix /ompi/installation 

If files with the .events.z or .def.z extensions have been created,
then _trace_files_exist() evaluates to true.

Why don't we create another funclet to run "otfinfo" on the trace
files? I can create it, I just need to know what "otfinfo" does to
confirm that the trace files are good.

-Ethan


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


[MTT devel] Uh testbake runs

2007-10-02 Thread Jeff Squyres (jsquyres)
I'm away from a computer right now so I don't have the specifics, but we saw 
some testbake results from UH today of mpich2 under slurm that were not run 
properly - it ran 16 copies of skampi instead of 1 16-node job, so the output 
was very skewed (and completely mis-parsed).

Can you check your mpich2 compile / link settings to ensure that you're linking 
against the slurm pmi library properly?

-jms