Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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.
>
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB