[jira] [Created] (MAPREDUCE-6762) ControlledJob#toString failed with NPE when job status is not successfully updated

Weiwei Yang created MAPREDUCE-6762: -- Summary: ControlledJob#toString failed with NPE when job status is not successfully updated Key: MAPREDUCE-6762 URL: https://issues.apache.org/jira/browse/MAPREDUCE-6762

[jira] [Created] (MAPREDUCE-6761) Regression when handling providers - invalid configuration ServiceConfiguration causes Cluster initialization failure

Peter Vary created MAPREDUCE-6761: - Summary: Regression when handling providers - invalid configuration ServiceConfiguration causes Cluster initialization failure Key: MAPREDUCE-6761 URL:

Re: [VOTE] Release Apache Hadoop 2.7.3 RC2

Thanks Vinod for creating new RC for 2.7.3 release. +1 (binding) based on following verifications: - Download src and binary tar ball and verify signature (gpg --verify). - Build from source Java 1.8.0_31-b13 on Mac native successfully. - Build from source with Java 1.7.0_79-b15 on Ubuntu VM

Re: [VOTE] Release Apache Hadoop 2.7.3 RC1

Hi All, Thank you for all the inputs on HDFS-9395. I have opened HDFS-10776 to discuss the modifications needed for audit logging to be consistent and comprehensive. We can move this discussion to the new JIRA. Appreciate the support. Regards,Kuhu Shukla On Thursday, August 18, 2016 12:04

Re: [VOTE] Release Apache Hadoop 2.7.3 RC1

> What is a realistic strategy for us to evolve the HDFS audit log in a backward-compatible way? If the API is essentially any form of ad-hoc scripting, then for any proposed audit log format change, I can find a reason to veto it on grounds of backward incompatibility. Yeah when log scraping is

Re: [VOTE] Release Apache Hadoop 2.7.3 RC1

Andrew, thanks for adding your perspective on this. What is a realistic strategy for us to evolve the HDFS audit log in a backward-compatible way? If the API is essentially any form of ad-hoc scripting, then for any proposed audit log format change, I can find a reason to veto it on grounds

Re: [VOTE] Release Apache Hadoop 2.7.3 RC1

I believe it was described as some previous audit entries have been superseded by new ones and that the order may no longer be the same for other entries. For what it’s worth, I agree with the assertion that this is a backward incompatible output - especially for audit logs. On Thu, Aug 18, 2016

Re: [VOTE] Release Apache Hadoop 2.7.3 RC1

An incompatible APIs change is developer unfriendly. An incompatible behavioral change is operator unfriendly. Historically, one dimension of incompatibility has had a lot more mindshare than the other. It's great that this might be changing for the better. Where I work when we move from one

Re: [VOTE] Release Apache Hadoop 2.7.3 RC1

> On 18 Aug 2016, at 14:57, Junping Du wrote: > > I think Allen's previous comments are very misleading. > In my understanding, only incompatible API (RPC, CLIs, WebService, etc.) > shouldn't land on branch-2, but other incompatible behaviors (logs, > audit-log,

Apache Hadoop qbt Report: trunk+JDK8 on Linux/x86

For more details, see https://builds.apache.org/job/hadoop-qbt-trunk-java8-linux-x86/137/ [Aug 17, 2016 10:04:58 AM] (vvasudev) YARN-5455. Update Javadocs for LinuxContainerExecutor. Contributed by [Aug 17, 2016 4:22:31 PM] (jlowe) MAPREDUCE-6690. Limit the number of resources a single map

Re: [VOTE] Release Apache Hadoop 2.7.3 RC1

I think Allen's previous comments are very misleading. In my understanding, only incompatible API (RPC, CLIs, WebService, etc.) shouldn't land on branch-2, but other incompatible behaviors (logs, audit-log, daemon's restart, etc.) should get flexible for landing. Otherwise, how could 52 issues

[jira] [Created] (MAPREDUCE-6760) LocatedFileStatusFetcher to use listFiles(recursive)

Steve Loughran created MAPREDUCE-6760: - Summary: LocatedFileStatusFetcher to use listFiles(recursive) Key: MAPREDUCE-6760 URL: https://issues.apache.org/jira/browse/MAPREDUCE-6760 Project: Hadoop