[jira] [Resolved] (YARN-4679) When work-preserving restart is enabled, the scheduler should wait for the earlier of recovery completion and configured wait time

[ https://issues.apache.org/jira/browse/YARN-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karthik Kambatla resolved YARN-4679. Resolution: Duplicate Closing this as a duplicate of YARN-2567. > When work-preserving

Hadoop-Yarn-trunk-Java8 - Build # 1032 - Still Failing

See https://builds.apache.org/job/Hadoop-Yarn-trunk-Java8/1032/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 5243 lines...] Java HotSpot(TM) 64-Bit Server VM

Build failed in Jenkins: Hadoop-Yarn-trunk-Java8 #1032

See Changes: [jlowe] Update CHANGES.txt to reflect recent commits to branch-2.7 and -- [...truncated 5050 lines...] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.227

[jira] [Created] (YARN-4681) ProcfsBasedProcessTree should not calculate private clean pages

Jan Lukavsky created YARN-4681: -- Summary: ProcfsBasedProcessTree should not calculate private clean pages Key: YARN-4681 URL: https://issues.apache.org/jira/browse/YARN-4681 Project: Hadoop YARN

Re: ProcFsBasedProcessTree and clean pages in smaps

Hi Chris and Varun, thanks for you suggestions. I played around with the cgroups, and I think that although it kind of resolves memory issues, I think it doesn't fit our needs, because of other restrictions enforced on the container (mainly the CPU restrictions). I created

[jira] [Created] (YARN-4682) AMRM client to log when AMRM token updated

Steve Loughran created YARN-4682: Summary: AMRM client to log when AMRM token updated Key: YARN-4682 URL: https://issues.apache.org/jira/browse/YARN-4682 Project: Hadoop YARN Issue Type:

Re: [VOTE] Release Apache Hadoop 2.6.4 RC0

+1 (non-binding) - Built source- Deployed a single node cluster- Ran a sample streaming job- Ran basic hadoop fs commands. Thanks Junping!Regards,Kuhu On Tuesday, February 9, 2016 8:46 AM, Wangda Tan wrote: +1 (binding) - Deployed a local cluster. - Configured

Re: [VOTE] Release Apache Hadoop 2.6.4 RC0

Hi Eric, replaceLabelsOnNode CLI syntax is different between 2.6 and 2.7. As mentioned by Naga, In 2.6, you should use "node1<:port>,label node2,label ..." And in 2.7, you can use either "," or "=" to separate host and label. So 2.7 is backward-compatible to 2.6, but it's not guaranteed that

Re: [VOTE] Release Apache Hadoop 2.6.4 RC0

+1 (non-binding) with one note, - Installed tar ball from source and brought up the cluster - Ran few MR jobs and those are working fine. - UI and REST apis are also looks fine. Ran few rest queries for this test. - Tested node label feature and works fine. (one observation during this testing)

[jira] [Created] (YARN-4683) Document the List Reservations REST API

Sean Po created YARN-4683: - Summary: Document the List Reservations REST API Key: YARN-4683 URL: https://issues.apache.org/jira/browse/YARN-4683 Project: Hadoop YARN Issue Type: Task

Hadoop-Yarn-trunk-Java8 - Build # 1033 - Still Failing

See https://builds.apache.org/job/Hadoop-Yarn-trunk-Java8/1033/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 5938 lines...] Java HotSpot(TM) 64-Bit Server VM

Jenkins build is back to normal : Hadoop-Yarn-trunk #1744

See

Build failed in Jenkins: Hadoop-Yarn-trunk-Java8 #1033

See Changes: [aajisaka] MAPREDUCE-6626. Reuse ObjectMapper instance in MapReduce. Contributed by [aajisaka] HDFS-9784. Example usage is not correct in Transparent Encryption --

Re: [Release thread] 2.8.0 release activities

Sure. The last time I checked, there were 20 odd blocker/critical tickets too that’ll need some of my time. Given that, if you can get them in before a week, we should be good. +Vinod > On Feb 5, 2016, at 1:19 PM, Subramaniam V K wrote: > > Vinod, > > Thanks for

Hadoop-Yarn-trunk - Build # 1743 - Still Failing

See https://builds.apache.org/job/Hadoop-Yarn-trunk/1743/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 9328 lines...] Tests run: 16, Failures: 0, Errors: 0,

Build failed in Jenkins: Hadoop-Yarn-trunk #1743

See Changes: [jlowe] Update CHANGES.txt to reflect recent commits to branch-2.7 and -- [...truncated 9135 lines...] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.289 sec -

Re: [VOTE] Release Apache Hadoop 2.6.4 RC0

+1(binding) - Verified signatures. - Ran tests for Apache Tez with the artifacts. All tests passed. - Ran local cluster and ran some examples on it. - Tsuyoshi On Wed, Feb 10, 2016 at 2:18 AM, Sunil Govind wrote: > +1 (non-binding) with one note, > > - Installed tar

Hadoop-Yarn-trunk-Java8 - Build # 1035 - Failure

See https://builds.apache.org/job/Hadoop-Yarn-trunk-Java8/1035/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 5479 lines...] Java HotSpot(TM) 64-Bit Server VM

Build failed in Jenkins: Hadoop-Yarn-trunk #1746

See Changes: [uma.gangumalla] HDFS-9779 . TestReplicationPolicyWithNodeGroup NODE variable picks wrong -- [...truncated 10537 lines...] Results : Tests run: 11, Failures: 0, Errors: 0,

Hadoop-Yarn-trunk - Build # 1746 - Still Failing

See https://builds.apache.org/job/Hadoop-Yarn-trunk/1746/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 10730 lines...] Caused by:

Build failed in Jenkins: Hadoop-Yarn-trunk-Java8 #1035

See Changes: [uma.gangumalla] HDFS-9779 . TestReplicationPolicyWithNodeGroup NODE variable picks wrong -- [...truncated 5286 lines...] [INFO] [INFO] ---

[jira] [Created] (YARN-4684) TestYarnCLI#testGetContainers failing in trunk

Bibin A Chundatt created YARN-4684: -- Summary: TestYarnCLI#testGetContainers failing in trunk Key: YARN-4684 URL: https://issues.apache.org/jira/browse/YARN-4684 Project: Hadoop YARN Issue

[jira] [Created] (YARN-4685) AM blacklist addition/removal should get updated for every allocate call from RMAppAttemptImpl.

Rohith Sharma K S created YARN-4685: --- Summary: AM blacklist addition/removal should get updated for every allocate call from RMAppAttemptImpl. Key: YARN-4685 URL: https://issues.apache.org/jira/browse/YARN-4685

Re: [VOTE] Release Apache Hadoop 2.6.4 RC0

Thanks Yongjun for identifying and proposing this change to 2.6.4. I think this is the right thing to do and check for following releases. For 2.6.4, it seems unnecessary to create another release candidate for this issue as we only kicking off a new RC build when last RC has serious problem in