From spitzcor at cray.com  Tue Aug  7 04:55:44 2012
From: spitzcor at cray.com (Cory Spitz)
Date: Mon, 6 Aug 2012 23:55:44 -0500
Subject: [lustre-devel] merges to b2_<x>
Message-ID: <50209FD0.8000306@cray.com>

Hi.

We at Cray have been looking at b2_1 landings, and one thing that I 
think would be nice is if we could identify the master commit that the 
b2_1 commit is based on directly from the mod header.  Unless, of 
course, there is an easy way to derive this information via git.  I hope 
that this isn't a stupid question, but is there?  It seems to me that 
since most b2_1 commits are cherry picked that we lose that bit.  It 
seems that git cherry-pick -x might be useful here.  Is that all we need?

If there isn't an easy way for git to provide the lineage, would we be 
able to add an additional commit tag or just advertise a convention to 
follow at http://wiki.whamcloud.com/display/PUB/Commit+Comments?

Thanks,
-Cory

From surya1 at llnl.gov  Tue Aug  7 16:08:54 2012
From: surya1 at llnl.gov (Prakash Surya)
Date: Tue, 7 Aug 2012 09:08:54 -0700
Subject: [lustre-devel] [Lustre-devel] merges to b2_<x>
In-Reply-To: <50209FD0.8000306@cray.com>
References: <50209FD0.8000306@cray.com>
Message-ID: <20120807160854.GL6857@llnl.gov>

Looking at the man page for git-cherry-pick, I'm not sure the "-x"
option would entirely work:

    "Append the note only for cherry picks without conflicts."

How often do the backported patches apply without conflicts? With the
amount of code change taking place, my guess is conflicts are normal
operation. A developer enforced convention detailing the commit
backported and perhaps what and why changes were necessary to apply
cleanly would suffice. So long as it doesn't clutter the commit message.

Another way to do this would be to use the same Change-Id field for the
backported patch. One could grep for the Change-Id in the commit logs
relatively easily, although I'm not sure how the review system would
handle this.

-- 
Cheers, Prakash

On Mon, Aug 06, 2012 at 09:55:44PM -0700, Cory Spitz wrote:
> Hi.
> 
> We at Cray have been looking at b2_1 landings, and one thing that I 
> think would be nice is if we could identify the master commit that the 
> b2_1 commit is based on directly from the mod header.  Unless, of 
> course, there is an easy way to derive this information via git.  I hope 
> that this isn't a stupid question, but is there?  It seems to me that 
> since most b2_1 commits are cherry picked that we lose that bit.  It 
> seems that git cherry-pick -x might be useful here.  Is that all we need?
> 
> If there isn't an easy way for git to provide the lineage, would we be 
> able to add an additional commit tag or just advertise a convention to 
> follow at http://wiki.whamcloud.com/display/PUB/Commit+Comments?
> 
> Thanks,
> -Cory
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-devel

From morrone2 at llnl.gov  Tue Aug  7 17:27:08 2012
From: morrone2 at llnl.gov (Christopher J. Morrone)
Date: Tue, 07 Aug 2012 10:27:08 -0700
Subject: [lustre-devel] merges to b2_<x>
In-Reply-To: <50209FD0.8000306@cray.com>
References: <50209FD0.8000306@cray.com>
Message-ID: <50214FEC.3060605@llnl.gov>

Generally we keep the first line of the commit message the same.  We 
should probably make that explicit policy, actually, if it isn't 
already.  That is usually what I use to correlate patches.

I think the git commit would be problematic to use at times.  For 
instance, consider the case where both the master and b2_1 patches are 
developed in parallel (rather than waiting for the final commit on one 
branch before starting the other).  The commit ID will change until the 
final commit is pushed to the central repo.

If we don't just use the subject line (my preference, because it is easy 
to compare using "git log --oneline"), we could add another meta-field 
that references the other change's gerrit Change-Id.  But there are 
already lots of meta-fields...

Chris

On 08/06/2012 09:55 PM, Cory Spitz wrote:
> Hi.
>
> We at Cray have been looking at b2_1 landings, and one thing that I
> think would be nice is if we could identify the master commit that the
> b2_1 commit is based on directly from the mod header.  Unless, of
> course, there is an easy way to derive this information via git.  I hope
> that this isn't a stupid question, but is there?  It seems to me that
> since most b2_1 commits are cherry picked that we lose that bit.  It
> seems that git cherry-pick -x might be useful here.  Is that all we need?
>
> If there isn't an easy way for git to provide the lineage, would we be
> able to add an additional commit tag or just advertise a convention to
> follow at http://wiki.whamcloud.com/display/PUB/Commit+Comments?
>
> Thanks,
> -Cory
> _______________________________________________
> lustre-devel mailing list
> lustre-devel at lists.opensfs.org
> http://lists.opensfs.org/listinfo.cgi/lustre-devel-opensfs.org
>


From adilger at whamcloud.com  Tue Aug  7 19:45:43 2012
From: adilger at whamcloud.com (Andreas Dilger)
Date: Tue, 7 Aug 2012 13:45:43 -0600
Subject: [lustre-devel] [Lustre-devel] merges to b2_<x>
In-Reply-To: <20120807160854.GL6857@llnl.gov>
References: <50209FD0.8000306@cray.com> <20120807160854.GL6857@llnl.gov>
Message-ID: <E6EEE694-681F-4414-A41C-AD634C17800B@whamcloud.com>

On 2012-08-07, at 10:08 AM, Prakash Surya wrote:
> Looking at the man page for git-cherry-pick, I'm not sure the "-x"
> option would entirely work:
> 
>    "Append the note only for cherry picks without conflicts."
> 
> How often do the backported patches apply without conflicts? With the
> amount of code change taking place, my guess is conflicts are normal
> operation. A developer enforced convention detailing the commit
> backported and perhaps what and why changes were necessary to apply
> cleanly would suffice. So long as it doesn't clutter the commit message.

I agree that having some standardized way of linking two commits on different branches would be quite useful.  In some cases, Oleg is able to do a cherry-pick of the original patch from master to b2_1, but in other cases there are separate patches submitted to Gerrit (with separate Change-Ids) for each branch in order to simplify patch testing.

> Another way to do this would be to use the same Change-Id field for the
> backported patch. One could grep for the Change-Id in the commit logs
> relatively easily, although I'm not sure how the review system would
> handle this.

Using the same Change-Id on two different branches causes heartburn for Gerrit, unfortunately.  This has happened by accident a few times, when a series of patches were merged into a development branch and then accidentally pushed to Gerrit.  It thinks that these previously-landed patches are all "in progress" again, and causes every later patch on the original branch (usually master) to claim them as open dependencies.

I'd rather have standardized keyword(s) that contain the original Git commit from master, and possibly the original Change-Id value.  There is already a "{name}-bug-id:" tag in use for tracking a patch from different upstream ticketing systems (e.g. Xyratex, Oracle, Whamcloud).

Cheers, Andreas

> On Mon, Aug 06, 2012 at 09:55:44PM -0700, Cory Spitz wrote:
>> Hi.
>> 
>> We at Cray have been looking at b2_1 landings, and one thing that I 
>> think would be nice is if we could identify the master commit that the 
>> b2_1 commit is based on directly from the mod header.  Unless, of 
>> course, there is an easy way to derive this information via git.  I hope 
>> that this isn't a stupid question, but is there?  It seems to me that 
>> since most b2_1 commits are cherry picked that we lose that bit.  It 
>> seems that git cherry-pick -x might be useful here.  Is that all we need?
>> 
>> If there isn't an easy way for git to provide the lineage, would we be 
>> able to add an additional commit tag or just advertise a convention to 
>> follow at http://wiki.whamcloud.com/display/PUB/Commit+Comments?
>> 
>> Thanks,
>> -Cory
>> _______________________________________________
>> Lustre-devel mailing list
>> Lustre-devel at lists.lustre.org
>> http://lists.lustre.org/mailman/listinfo/lustre-devel
> _______________________________________________
> lustre-devel mailing list
> lustre-devel at lists.opensfs.org
> http://lists.opensfs.org/listinfo.cgi/lustre-devel-opensfs.org


Cheers, Andreas
--
Andreas Dilger                       Whamcloud, Inc.
Principal Lustre Engineer            http://www.whamcloud.com/




From bruce_korb at xyratex.com  Tue Aug  7 21:00:57 2012
From: bruce_korb at xyratex.com (Bruce Korb)
Date: Tue, 07 Aug 2012 14:00:57 -0700
Subject: [lustre-devel] [Lustre-devel] merges to b2_<x>
In-Reply-To: <E6EEE694-681F-4414-A41C-AD634C17800B@whamcloud.com>
Message-ID: <CC46CE84.5D03%bruce_korb@xyratex.com>

Hi Andreas,

On 8/7/12 12:45 PM, Andreas Dilger wrote:
>> Another way to do this would be to use the same Change-Id field for the
>> backported patch. One could grep for the Change-Id in the commit logs
>> relatively easily, although I'm not sure how the review system would
>> handle this.
>
>Using the same Change-Id on two different branches causes heartburn for
>Gerrit, unfortunately.  This has happened by accident a few times, when a
>series of patches were merged into a development branch and then
>accidentally pushed to Gerrit.  It thinks that these previously-landed
>patches are all "in progress" again, and causes every later patch on the
>original branch (usually master) to claim them as open dependencies.

Maybe you could find some script maestro who could auto-insert this
magic tag at the same time the original Change-Id gets inserted?
Commit-Id: anyone?


From briano at sgi.com  Thu Aug  9 02:41:57 2012
From: briano at sgi.com (Brian O'Connor)
Date: Thu, 9 Aug 2012 12:41:57 +1000
Subject: [lustre-devel] Is network interface fail-over on same server on the
	road map?
Message-ID: <50232375.8090307@sgi.com>


Hi

    at present AFAIK a lustre connection will not failover between NIDS 
on the same server. For example if you have a 2 MDS servers with two IB 
interfaces and an ETH interface configured as a HA pair, you can 
configure the client to *mount* on the basis of which they can see, but 
once the connection is made if the network switch, cable or HCA fails 
then the client cannot failover to the other NID on the *same* server, 
it fails over to a NID on the HA pair (and the resources probably wont 
be on the HA pair)

So my question is... is this  feature on a road map, or is it just not 
compatible with other aspects of Lustre.

So,  to try and be clear, assuming the following;

Servers
MDS1:  ib0=192.168.1.1/24, ib1=192.168.2.1/24, eth0=10.0.0.1/24
MDS2:  ib0=192.168.1.2/24, ib1=192.168.2.2/24, eth0=10.0.0.2/24
OSS1:  ib0=192.168.1.11/24, ib1=192.168.2.11/24, eth0=10.0.0.11/24
..
OSS20: ib0=192.168.1.30/24, ib1=192.168.2.30/24, eth0=10.0.0.30/24

Clients

c1:    ib0=192.168.1.101/24, ib1=192.168.2.101/24, eth0=10.0.0.101/24
..
c100:  ib0=192.168.1.200/24, ib1=192.168.2.200/24, eth0=10.0.0.200/24

I mount on the client with

mount -t lustre 
192.168.1.1 at o2ib,192.168.2.1 at o2ib,10.0.0.1 at tcp:192.168.1.2 at o2ib,192.168.2.2 at o2ib,10.0.0.2 at tcp:/lustre 
/lustre

(and setup to load balance odd/even clients to odd/even ips on servers)

client "c1" mounts initially via 192.168.1.1 at o2ib. If later the client 
fails to communicate on  192.168.1.1 at o2ib at present it will *not* try 
192.168.2.1 or 10.0.0.1, it will try  192.168.1.2 or 192.168.2.2  or 
10.0.0.2  on the configured HA pair. This complicates the HA setup in 
that you have to monitor the networks, and stonith all the mds/oss so 
that the resources are available on the HA pair when needed, and so far 
this has never worked out for me.

Is there an architectural reason that you can't failover over to another 
NID on the same server?



-- 
Brian O'Connor
-------------------------------------------------------------
SGI Consulting
Email: briano at sgi.com, Mobile +61 417 746 452
Phone: +61 3 9963 1900, Fax:  +61 3 9963 1902
691 Burke Road, Camberwell, Victoria, 3124
AUSTRALIA
http://www.sgi.com/support/services
-------------------------------------------------------------

From nathan_rutman at xyratex.com  Thu Aug  9 03:55:00 2012
From: nathan_rutman at xyratex.com (Nathan Rutman)
Date: Wed, 8 Aug 2012 20:55:00 -0700
Subject: [lustre-devel] Is network interface fail-over on same server on
	the road map?
In-Reply-To: <50232375.8090307@sgi.com>
References: <50232375.8090307@sgi.com>
Message-ID: <99E80A50-0E13-4672-81FA-9CCC4FBDF9C4@xyratex.com>

You are correct.  A node will choose a single Lnet network (ib0, ib1, or eth0) over which to talk at the establishment of the connection, and never change its mind.  If the server becomes unresponsive, the client will try one network on the failover list. 
The reason why you can't failover to a second network is that the server state in that case is not "just failed over and awaiting replay" but is instead "perfectly happy in normal operating mode", and so doesn't know what to do with this new client who wants to do replay. 
This could be fixed by some more sophisticated handling on the server, or a new Lnet failover mode, but I don't think this is in anybody's plans at the moment. 



On Aug 8, 2012, at 7:41 PM, Brian O'Connor <briano at sgi.com> wrote:

> 
> Hi
> 
>   at present AFAIK a lustre connection will not failover between NIDS on the same server. For example if you have a 2 MDS servers with two IB interfaces and an ETH interface configured as a HA pair, you can configure the client to *mount* on the basis of which they can see, but once the connection is made if the network switch, cable or HCA fails then the client cannot failover to the other NID on the *same* server, it fails over to a NID on the HA pair (and the resources probably wont be on the HA pair)
> 
> So my question is... is this  feature on a road map, or is it just not compatible with other aspects of Lustre.
> 
> So,  to try and be clear, assuming the following;
> 
> Servers
> MDS1:  ib0=192.168.1.1/24, ib1=192.168.2.1/24, eth0=10.0.0.1/24
> MDS2:  ib0=192.168.1.2/24, ib1=192.168.2.2/24, eth0=10.0.0.2/24
> OSS1:  ib0=192.168.1.11/24, ib1=192.168.2.11/24, eth0=10.0.0.11/24
> ..
> OSS20: ib0=192.168.1.30/24, ib1=192.168.2.30/24, eth0=10.0.0.30/24
> 
> Clients
> 
> c1:    ib0=192.168.1.101/24, ib1=192.168.2.101/24, eth0=10.0.0.101/24
> ..
> c100:  ib0=192.168.1.200/24, ib1=192.168.2.200/24, eth0=10.0.0.200/24
> 
> I mount on the client with
> 
> mount -t lustre 192.168.1.1 at o2ib,192.168.2.1 at o2ib,10.0.0.1 at tcp:192.168.1.2 at o2ib,192.168.2.2 at o2ib,10.0.0.2 at tcp:/lustre /lustre
> 
> (and setup to load balance odd/even clients to odd/even ips on servers)
> 
> client "c1" mounts initially via 192.168.1.1 at o2ib. If later the client fails to communicate on  192.168.1.1 at o2ib at present it will *not* try 192.168.2.1 or 10.0.0.1, it will try  192.168.1.2 or 192.168.2.2  or 10.0.0.2  on the configured HA pair. This complicates the HA setup in that you have to monitor the networks, and stonith all the mds/oss so that the resources are available on the HA pair when needed, and so far this has never worked out for me.
> 
> Is there an architectural reason that you can't failover over to another NID on the same server?
> 
> 
> 
> -- 
> Brian O'Connor
> -------------------------------------------------------------
> SGI Consulting
> Email: briano at sgi.com, Mobile +61 417 746 452
> Phone: +61 3 9963 1900, Fax:  +61 3 9963 1902
> 691 Burke Road, Camberwell, Victoria, 3124
> AUSTRALIA
> http://www.sgi.com/support/services
> -------------------------------------------------------------
> _______________________________________________
> lustre-devel mailing list
> lustre-devel at lists.opensfs.org
> http://lists.opensfs.org/listinfo.cgi/lustre-devel-opensfs.org