Allen is right. This is a huge new feature with 86 jiras already filed, which substantially increases the complexity of the code base. Having an in-depth motivation and benchmarking will be needed before the community decides on adopting it for support. Thanks, --Konstantin
On Sat, Mar 12, 2011 at 8:43 AM, Allen Wittenauer <awittena...@linkedin.com>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. > >
