Re: [VOTE] Merging branch HDFS-7240 to trunk

> On Mar 5, 2018, at 4:08 PM, Andrew Wang wrote: > > - NN on top HDSL where the NN uses the new block layer (Both Daryn and Owen > acknowledge the benefit of the new block layer). We have two choices here > ** a) Evolve NN so that it can interact with both old and

Re: [VOTE] Merging branch HDFS-7240 to trunk

Joep, You raise a number of points: (1) Ozone vs and object stores. “Some users would choose Ozone as that layer, some might use S3, others GCS, or Azure, or something else”. (2) How HDSL/Ozone fits into Hadoop and whether it is necessary. (3) You raise the release issue which we will respond

Re: [VOTE] Merging branch HDFS-7240 to trunk

HDSL), which >> is >>> a distributed, replicated block layer. >>>The old HDFS namespace and NN can be connected to this new block >> layer >>> as we have described in HDFS-10419. >>>We also introduce a key-value namespace called Ozone built on HDSL. &

Re: [DISCUSSION] Merging HDFS-7240 Object Store (Ozone) to trunk

Konstantine Thanks for your feedback and comments over the last few months. Have we addressed all your issues and concerns? sanjay > On Feb 13, 2018, at 6:28 PM, sanjay Radia <sanjayo...@gmail.com> wrote: > > Sorry the formatting got messed by my email client. H

Re: [DISCUSSION] Merging HDFS-7240 Object Store (Ozone) to trunk

Sorry the formatting got messed by my email client. Here it is again Dear Hadoop Community Members, We had multiple community discussions, a few meetings in smaller groups and also jira discussions with respect to this thread. We express our gratitude for participation and valuable

Re: [DISCUSSION] Merging HDFS-7240 Object Store (Ozone) to trunk

Dear Hadoop Community Members, We had multiple community discussions, a few meetings in smaller groups and also jira discussions with respect to this thread. We express our gratitude for participation and valuable comments. The key questions raised were following How the new block storage

Re: [DISCUSSION] Merging HDFS-7240 Object Store (Ozone) to trunk

Konstantine, Thanks for your comments, questions and feedback. I have attached a document to the HDFS-7240 jira that explains a design for scaling HDFS and how Ozone paves the way towards the full solution.

Re: LinkedIn Dynamometer Tool (was About 2.7.4 Release)

Erik Great stuff. BTW did you build on top of the “simulated data nodes” in HDFS which has a way to storing only the length of data (but not real data)? That work allowed supplementing with a matching editsLog for the NN. Your approach of using a real image has the advantage of being able

Re: Looking to a Hadoop 3 release

On Mar 5, 2015, at 3:21 PM, Siddharth Seth ss...@apache.org wrote: 2) Simplification of configs - potentially separating client side configs and those used by daemons. This is another source of perpetual confusion for users. + 1 on this. sanjay

Re: Looking to a Hadoop 3 release

On Mar 3, 2015, at 9:36 AM, Karthik Kambatla ka...@cloudera.com wrote: If we preserve API compat and try to preserve wire compat, I don't see the harm in bumping the major release. If we preserve compatibility, then there is no need to bump major number. It allows us to include several

Re: Looking to a Hadoop 3 release

Andrew Thanks for bringing up the issue of moving to Java8. Java8 is important However, I am not seeing a strong motivation for changing the major number. We can go to Java8 in the 2.series. The classpath issue for Hadoop-11656 is too minor to force a major number change (no pun intended).

Re: [VOTE] Migration from subversion to git for version control

+1 sanjay On Fri, Aug 8, 2014 at 7:57 PM, Karthik Kambatla ka...@cloudera.com wrote: I have put together this proposal based on recent discussion on this topic. Please vote on the proposal. The vote runs for 7 days. 1. Migrate from subversion to git for version control. 2.

Re: [Vote] Merge branch-trunk-win to trunk

On Mar 1, 2013, at 1:57 PM, Konstantin Shvachko wrote: Commitment is a good thing. I think the two builds that I proposed are a prerequisite for Win support. If we commit windows patch people will start breaking it the next day. Which we wont know without the nightly build and wont be able

Re: [Vote] Merge branch-trunk-win to trunk

+1 Java has done the bulk of the work in making Hadoop multi-platform. Windows specific code is a tiny percentage of the code. Jeninks support for windows is going help us keep the platform portable going forward. I expect that the vast majority of new commits have no problems. I propose that