Re: [MTT devel] [devel-core] MTT on ivy

2015-12-03 Thread Christoph Niethammer
Hello,

Escaping the parentheses helps:
^ivy cluster \(sj\)$

PS: I like regex :)

Regards
Christoph Niethammer

- Original Message -
From: "Gilles Gouaillardet" <gilles.gouaillar...@gmail.com>
To: "Open MPI Core Developers" <devel-c...@open-mpi.org>
Cc: "mtt-devel" <mtt-de...@open-mpi.org>
Sent: Thursday, December 3, 2015 2:41:07 PM
Subject: Re: [devel-core] MTT on ivy

Sylvain, 

I incidentally found the '(sj)' is giving mtt web a hard time. 
for example, if i click on the links to see the latest build failures, mtt 
reports nothing. 
a workaround is to replace 
^ivy cluster (sj)$ 
with 
^ivy 
I guess the (sj) is interpreted as a regex by mtt web and this is not what we 
would have expected here 

for the time being, can you remove the parenthesis ? 

Cheers, 

Gilles 

On Wednesday, December 2, 2015, Sylvain Jeaugey < sjeau...@nvidia.com > wrote: 


That was exactly the kind of feature I was looking for. Thanks ! 

On 12/01/2015 11:42 AM, Jeff Squyres (jsquyres) wrote: 




On Dec 1, 2015, at 1:16 PM, Sylvain Jeaugey < sjeau...@nvidia.com > wrote: 

My results will be marked as "ivy cluster (sj)" while I'm playing with the test 
scripts. When the results look good, I will remove the "(sj)". 
You can also use the "trial=1" value in the INI file to mark your results as 
trials (that are not shown by default searches on the web interface). 



---
 
This email message is for the sole use of the intended recipient(s) and may 
contain 
confidential information. Any unauthorized review, use, disclosure or 
distribution 
is prohibited. If you are not the intended recipient, please contact the sender 
by 
reply email and destroy all copies of the original message. 
---
 
___ 
devel-core mailing list 
devel-c...@open-mpi.org 
http://www.open-mpi.org/mailman/listinfo.cgi/devel-core 

___
devel-core mailing list
devel-c...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel-core


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

2014-06-30 Thread Christoph Niethammer
Hello,

A fast forward merge does not create a single merge commit but takes all 
commits and applies them to the current branch.[1]
So this will do what Jeff intended without the necessity of deleting and 
recreating a static tag or editing version numbers in update scripts. ;)

Regards
Christoph

[1] http://ariya.ofilabs.com/2013/09/fast-forward-git-merge.html


- Original Message -
From: "Gilles Gouaillardet" <gilles.gouaillar...@iferc.org>
To: "Development list for the MPI Testing Tool" <mtt-de...@open-mpi.org>
Sent: Monday, June 30, 2014 4:06:34 AM
Subject: Re: [MTT devel] MTT: let's use git tags

Jeff,

What i meant by "less error prone" is "you use the stable branch by
default" so you do not checkout the dev/unstable
branch by default.

as you pointed, the level/frequency of MTT development is fairly low,
my idea would be to create a "dev" branch, and when the state of the dev
branch is "production ready", simply do a

git checkout master
git merge dev

that being said, i am far from mastering git and i cannot judge the pros
vs cons of this (merge) versus the fast forward
approach pointed by Christoph

Cheers,

Gilles


On 2014/06/27 16:11, Christoph Niethammer 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)
>

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

2014-06-27 Thread Christoph Niethammer
+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 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

[MTT devel] mtt-relay patch - create pid file when run as daemon

2013-09-30 Thread Christoph Niethammer
Hello,

As on many systems init scripts and the handling of services is based on pid 
files I extended the mtt-relay script as follows:

If run with the --daemon option
* Create file /var/run/mtt-relay.pid  if it does not exist and write the pid of 
the background process into it.
* exit with return value 1 if /var/run/mtt-relay.pid file exists.

Patch is attached.

Best regards
Christoph Niethammer

--

Christoph Niethammer
High Performance Computing Center Stuttgart (HLRS)
Nobelstrasse 19
70569 Stuttgart

Tel: ++49(0)711-685-87203
email: nietham...@hlrs.de
http://www.hlrs.de/people/niethammer--- /home/hpcmtt/mtt-trunk/client/mtt-relay.orig2013-09-30 11:35:59.637400212 +0200
+++ /home/hpcmtt/mtt-trunk/client/mtt-relay 2013-09-30 11:45:19.496180413 +0200
@@ -93,6 +93,10 @@
 # exit;
 # }
 
+my $pidfilename = "/var/run/mtt-relay.pid";
+if (-e $pidfilename) {
+exit 1;
+}
 my $master = new HTTP::Daemon
 LocalAddr => $HOST, LocalPort => $PORT or 
 die "Problem creating an HTTP::Daemon: $!";
@@ -103,6 +107,9 @@
 my $pid = fork();
 if($pid) {
 print "# Daemon Parent exiting\n";
+open PIDFILE, ">$pidfilename";
+print PIDFILE $pid;
+close PIDFILE;
 exit 0;
 } else {
 print "# Daemon Child process continuing\n";