Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HDFS >> mail # dev >> Merging Namenode Federation feature (HDFS-1052) to trunk


Copy link to this message
-
Re: Merging Namenode Federation feature (HDFS-1052) to trunk
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
<[EMAIL PROTECTED]>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.
>
>