Mailing-List: contact hdfs-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-dev@hadoop.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <D58B9535-DB62-4A96-8203-8025706F67CD@yahoo-inc.com>
From: Sanjay Radia <sradia@yahoo-inc.com>
To: "hdfs-dev@hadoop.apache.org" <hdfs-dev@hadoop.apache.org>
In-Reply-To: <55FE8C60-D827-45CF-94EE-B258187A52C8@linkedin.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: Merging Namenode Federation feature (HDFS-1052) to trunk
Date: Mon, 14 Mar 2011 10:57:40 -0700
References: <C9955915.16F52%sureshms@yahoo-inc.com>
 <55FE8C60-D827-45CF-94EE-B258187A52C8@linkedin.com>


On Mar 12, 2011, at 8:43 AM, Allen Wittenauer wrote:

>
> 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-1052 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 provide your feedback on either  
>> HDFS-1052 or its subtasks. New items that come out of the feedback  
>> will be addressed in new jiras.
>
>>
>> Current status of the development:
>> # The testing of this feature is underway. Most of the basic  
>> functionality has been tested both for a single namenode cluster  
>> (for backward compatibility) and with multiple namenodes.
>> # All the existing tests and newly added tests pass (same as trunk).
>>
>> We plan on merging this branch to trunk after a week or two. This  
>> will help us continue make future changes on the trunk. I will send  
>> an announcement before merging the federation branch into trunk.
>>
>
> 	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 grid much much harder for very little benefit.  In  
> particular, I don't see the difference between running multiple NN/ 
> DN combinations verses running federation, especially with client  
> side mount tables in play.


Main difference between independent HDFS clusters and HDFS federation  
is that in federation one can shares the storage of the DNs and the DNs.
There is a very detailed document that describes this on the Jira.

If you are running a single NN and you don't need the scaling then  
running and managing hadoop is for all practical purposes unchanged.


sanjay
>