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: [VOTE] Merging branch HDFS-7240 to trunk

e a key-value namespace called Ozone built on HDSL. >>> >>>The code is in a separate module and is turned off by default. In a >>> secure setup, HDSL and Ozone daemons cannot be started. >>> >>>The detailed documentation

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: Plans of moving towards JDK7 in trunk

On Jun 21, 2014, at 8:01 AM, Andrew Wang andrew.w...@cloudera.com wrote: This is why I'd like to keep my original proposal on the table: keep going with branch-2 in the near term, while working towards a JDK8-based Hadoop 3 by April next year. It doesn't need to be a big bang release either.

[jira] [Resolved] (MAPREDUCE-4260) Use JobObject to spawn tasks on Windows

[ https://issues.apache.org/jira/browse/MAPREDUCE-4260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Radia resolved MAPREDUCE-4260. - Resolution: Fixed Commit to the windows branch. Thanks Bikas. Use

[jira] [Resolved] (MAPREDUCE-4204) Refactor ProcfsBasedProcessTree to make the resource collection object pluggable

[ https://issues.apache.org/jira/browse/MAPREDUCE-4204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Radia resolved MAPREDUCE-4204. - Resolution: Fixed Thanks Bikas - Committed to branch-1-win

[jira] [Created] (MAPREDUCE-3898) Hadoop for Windows - Interfacing with Windows to manage MR tasks

Type: Improvement Reporter: Sanjay Radia -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see

[jira] [Resolved] (MAPREDUCE-2887) MR changes to match HADOOP-7524 (multiple RPC protocols)

[ https://issues.apache.org/jira/browse/MAPREDUCE-2887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjay Radia resolved MAPREDUCE-2887. - Resolution: Fixed Committed as part of HADOOP-7524 MR changes to match HADOOP-7524

[jira] [Created] (MAPREDUCE-2887) MR changes to match HADOOP-7524 (multiple RPC protocols)

: Improvement Reporter: Sanjay Radia Assignee: Sanjay Radia -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira