hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allen Wittenauer <awittena...@linkedin.com>
Subject Re: Merging Namenode Federation feature (HDFS-1052) to trunk
Date Sat, 12 Mar 2011 16:43:23 GMT

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

View raw message