The HDFS-5698 branch has been merged to trunk. We plan to continue to test
the feature on bigger clusters and to merge it to branch-2 next week.
Thanks,
Haohui
On Fri, Feb 7, 2014 at 3:59 PM, Haohui Mai wrote:
> With 3 binding +1 and 2 non-binding +1 votes, the vote has passed.
>
> The code wi
With 3 binding +1 and 2 non-binding +1 votes, the vote has passed.
The code will be merged soon (pending Jenkins). We will address any
remaining issues in trunk.
Thanks to everyone who voted and provided their feedback.
Regards,
Haohui
On Wed, Feb 5, 2014 at 12:47 PM, Chris Nauroth wrote:
> +
+1
Thank you, Haohui Mai and Jing Zhao. I'm definitely looking forward to
fewer metadata upgrades in the future. :-)
Chris Nauroth
Hortonworks
http://hortonworks.com/
On Mon, Feb 3, 2014 at 10:49 PM, Akira AJISAKA
wrote:
> +1 (non-binding).
>
> This feature is very good for the developers t
+1 (non-binding).
This feature is very good for the developers to reduce
the tasks for supporting FSImage compatibility.
Thanks,
Akira
(2014/01/31 7:37), Haohui Mai wrote:
Hello all,
I would like to call a vote to merge of the new protobuf-based FSImage into
trunk.
The changes introduce a pr
+1. This is an important feature that gets rid of all the custom
serialization and unnecessary code around it. Helps in rolling upgrade
scenarios too!
Nice job Haohui Mai and Jing Zhao!
On Thu, Jan 30, 2014 at 2:37 PM, Haohui Mai wrote:
> Hello all,
>
> I would like to call a vote to merge of
+1
This was very important improvement.
hope it release at 2.4
On Jan 31, 2014 6:37 AM, "Haohui Mai" wrote:
> Hello all,
>
> I would like to call a vote to merge of the new protobuf-based FSImage into
> trunk.
>
> The changes introduce a protobuf-based FSImage format into HDFS. It
> separates
Hi Todd,
This is a great question. I don't see a lot of work from the implementation
prospective. I anticipate that the branch-2 patch will be almost identical
to the one for trunk.
We plan on merging it into branch-2 after more testings. In my opinion it
should fit in the 2.4 timeline.
And to c
One question - what's the intention with this work with regard to branch-2?
Do you plan to merge it to branch-2, and if so, are you thinking for 2.4 or
later?
I'm a little afraid of the divergence between trunk and branch-2 in this
area, since we'll likely want to add new features which require
se
+1. I think this is a very useful improvement. In the past when I
wanted to add a new snapshot field which needs to be persisted in
fsimage, I found that I would break the binary compatibility thus some
workaround had to be used (see HDFS-5428). Now protobuf gives us this
flexibility to make these
Hello all,
I would like to call a vote to merge of the new protobuf-based FSImage into
trunk.
The changes introduce a protobuf-based FSImage format into HDFS. It
separates the responsibility of serializing and reconstructing the
namespace in the NameNode using Google's Protocol Buffers
(protobuf)
10 matches
Mail list logo
