>
> But this does make things easier. Although I'm still fairly
> confident that it adds too much complexity for little gain though.
Allen,can you please add details on what complexity you are talking about
here? (I have already asked this question many times)
>From code perspective it
>
>
> A few questions:
> - Do we have a clear definition for a cluster?
>
Cluster before federation is defined by list of datanodes in include file,
bound together by namespaceID of the namenode that these nodes bind to on
first registration with the namenode. In essence, namespaceID defines the
On Mar 21, 2011, at 4:08 PM, Sanjay Radia wrote:
>
> Allen, not sure if I explained the difference above.
> Base on the discussion we had at the Hug, I want to clarify a few things
Thanks for taking the time at HUG. (I've since figured out that I lost
your messages as part of my email
On Mar 21, 2011, at 6:08 PM, Sanjay Radia wrote:
>
> On Mar 14, 2011, at 10:57 AM, Sanjay Radia wrote:
>
>>
>> On Mar 12, 2011, at 8:43 AM, Allen Wittenauer wrote:
>>
>>>
>>> To me, this series of changes looks like it is going to make
>>> running a grid much much harder for very little
On Mar 14, 2011, at 10:57 AM, Sanjay Radia wrote:
On Mar 12, 2011, at 8:43 AM, Allen Wittenauer wrote:
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 mul
> Namenode code is not changed at all.
Want to make sure I qualify this right. The change is not significant, other
than notion of BPID that the NN uses is added.
That is a different motivation. The document talks about why you should use
> federation. I am asking about motivation of supporting the code base while
> not using it. At least this is how understand Allen's question and some of
> my colleagues'.
>
Namenode code is not changed at all. Datanode co
On Mon, Mar 14, 2011 at 11:19 PM, suresh srinivas wrote:
> Thanks for starting off the discussion.
>
> > This is a huge new feature with 86 jiras already filed, which
> substantially increases the complexity of the code base.
> These are 86 jiras file in a feature branch. We decided to make these
Thanks for starting off the discussion.
> This is a huge new feature with 86 jiras already filed, which
substantially increases the complexity of the code base.
These are 86 jiras file in a feature branch. We decided to make these
changes, in smaller increments, instead of a jumbo patch. This was
On Mon, Mar 14, 2011 at 6:12 PM, Konstantin Shvachko
wrote:
> Dhruba, good you are speaking up for federation.
> I consider it important as it means more support for the feature in the
> future.
>
> The purpose of my reply was to get this discussion going, as I found Allens
> question unanswered f
Dhruba, good you are speaking up for federation.
I consider it important as it means more support for the feature in the
future.
The purpose of my reply was to get this discussion going, as I found Allens
question unanswered for 2 weeks.
The concern he has seems legitimate to me. If ops think fede
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 docum
Hi folks,
The design for the federation work has been a published and there is a very
well-written design document. It explains the pros-and-cons of each design
point. It would be nice if more people can review this document and provide
comments on how to make it better. The implementation is in p
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
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
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 bran
16 matches
Mail list logo
