Mailing-List: contact hdfs-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-dev@hadoop.apache.org
Received-SPF: pass (nike.apache.org: domain of awittenauer@linkedin.com
 designates 69.28.149.24 as permitted sender)
DomainKey-Signature: s=prod; d=linkedin.com; c=nofws; q=dns;
  h=X-IronPort-AV:Received:From:To:Subject:Thread-Topic:
   Thread-Index:Date:Message-ID:References:In-Reply-To:
   Accept-Language:Content-Language:X-MS-Has-Attach:
   X-MS-TNEF-Correlator:x-originating-ip:Content-Type:
   Content-ID:Content-Transfer-Encoding:MIME-Version;
  b=AgxuA55VhEaImcb6pLqPTtoAaRtwjgqq7Lt59yhPLsO4h28dHaaANiaO
   Qmg/ut2k65ObpUiwwc+o2pNqUvT0PIHTCQI8kCTaWLBd2NvQzdQC4R7M3
   RaH0BTWKqlGTCkV;
From: Allen Wittenauer <awittenauer@linkedin.com>
To: "<hdfs-dev@hadoop.apache.org>" <hdfs-dev@hadoop.apache.org>
Subject: Re: Merging Namenode Federation feature (HDFS-1052) to trunk
Thread-Topic: Merging Namenode Federation feature (HDFS-1052) to trunk
Thread-Index: AcvZ9CB16UWsveqe70CVthPzv2UUWAHIzvgA
Date: Sat, 12 Mar 2011 16:43:23 +0000
Message-ID: <55FE8C60-D827-45CF-94EE-B258187A52C8@linkedin.com>
References: <C9955915.16F52%sureshms@yahoo-inc.com>
In-Reply-To: <C9955915.16F52%sureshms@yahoo-inc.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <00FC0EDAC45E724BACC90EA1CAE08F15@linkedin.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


On Mar 3, 2011, at 2:41 PM, Suresh Srinivas wrote:

> We have started pushing changes for namenode federation in to the feature=
 branch HDFS-1052. The work items are created as subtask of the jira HDFS-1=
052 and are based on the design document published in the same jira. By the=
 end of this week, we will complete pushing the changes to HDFS-1052 branch=
. Though the changes in these jiras are already committed, please do provid=
e your feedback on either HDFS-1052 or its subtasks. New items that come ou=
t of the feedback will be addressed in new jiras.

>=20
> Current status of the development:
> # The testing of this feature is underway. Most of the basic functionalit=
y has been tested both for a single namenode cluster (for backward compatib=
ility) and with multiple namenodes.
> # All the existing tests and newly added tests pass (same as trunk).
>=20
> We plan on merging this branch to trunk after a week or two. This will he=
lp us continue make future changes on the trunk. I will send an announcemen=
t before merging the federation branch into trunk.
>=20

	It sounds like merging into trunk is extremely premature.  That said, I'm =
still trying to understand the why's around this.

	To me, this series of changes looks like it is going to make running a gri=
d much much harder for very little benefit.  In particular, I don't see the=
 difference between running multiple NN/DN combinations verses running fede=
ration, especially with client side mount tables in play.