[jira] [Created] (YARN-1884) ContainerReport should have nodeHttpAddress
Zhijie Shen created YARN-1884: - Summary: ContainerReport should have nodeHttpAddress Key: YARN-1884 URL: https://issues.apache.org/jira/browse/YARN-1884 Project: Hadoop YARN Issue Type: Bug Reporter: Zhijie Shen Assignee: Zhijie Shen In web UI, we're going to show the node, which used to be to link to the NM web page. However, on AHS web UI, and RM web UI after YARN-1809, the node field has to be set to nodeID where the container is allocated. We need to add nodeHttpAddress to the containerReport to link users to NM web page -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (YARN-1809) Synchronize RM and Generic History Service Web-UIs
[ https://issues.apache.org/jira/browse/YARN-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhijie Shen updated YARN-1809: -- Attachment: YARN-1809.8.patch I upload a patch, which fixed some bugs I've found on the web pages. In addition, I've tested the new RM web UI on the secured cluster, via https. It was working fine as well. One issue I've found is that node in the old RM web UI is a link to the NM web page, however, the new RM web UI and AHS web UI uniformly get container report from ApplicationBaseProtocol and fill the web page with the report. The container report doesn't contain nodeHttpAddress yet. I filed a separate ticket to track this issue (YARN-1884). Temporally, I disable the link and just show the node ID where the container was running. Synchronize RM and Generic History Service Web-UIs -- Key: YARN-1809 URL: https://issues.apache.org/jira/browse/YARN-1809 Project: Hadoop YARN Issue Type: Bug Reporter: Zhijie Shen Assignee: Zhijie Shen Attachments: YARN-1809.1.patch, YARN-1809.2.patch, YARN-1809.3.patch, YARN-1809.4.patch, YARN-1809.5.patch, YARN-1809.5.patch, YARN-1809.6.patch, YARN-1809.7.patch, YARN-1809.8.patch After YARN-953, the web-UI of generic history service is provide more information than that of RM, the details about app attempt and container. It's good to provide similar web-UIs, but retrieve the data from separate source, i.e., RM cache and history store respectively. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (YARN-1869) Access to zkAcl should be synchronized in ZKRMStateStore#addStoreOrUpdateOps()
[
https://issues.apache.org/jira/browse/YARN-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13948954#comment-13948954
]
Tsuyoshi OZAWA commented on YARN-1869:
--
Thank you for contributing, Blue. IMO, we should hold more small lock from
performance's point of view.
{code}
} else {
synchronized(zkAcl) {
opList.add(Op.create(nodeCreatePath, tokenOs.toByteArray(), zkAcl,
CreateMode.PERSISTENT));
}
}
{code}
This can be done because zkAcl is initialized in initInternal() and is not
updated after that.
{code}
@Override
public synchronized void initInternal(Configuration conf) throws Exception {
...
zkAcl = RMZKUtils.getZKAcls(conf);
...
}
{code}
Access to zkAcl should be synchronized in ZKRMStateStore#addStoreOrUpdateOps()
--
Key: YARN-1869
URL: https://issues.apache.org/jira/browse/YARN-1869
Project: Hadoop YARN
Issue Type: Bug
Reporter: Ted Yu
Priority: Minor
Attachments: yarn-1869.patch
Here is related code:
{code}
} else {
opList.add(Op.create(nodeCreatePath, tokenOs.toByteArray(), zkAcl,
CreateMode.PERSISTENT));
}
{code}
The other methods accessing zkAcl are synchronized.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (YARN-1883) TestRMAdminService fails due to inconsistent entries in UserGroups
[
https://issues.apache.org/jira/browse/YARN-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tsuyoshi OZAWA updated YARN-1883:
-
Summary: TestRMAdminService fails due to inconsistent entries in UserGroups
(was: TetsRMAdminService fails due to inconsistent entries in UserGroups)
TestRMAdminService fails due to inconsistent entries in UserGroups
--
Key: YARN-1883
URL: https://issues.apache.org/jira/browse/YARN-1883
Project: Hadoop YARN
Issue Type: Bug
Affects Versions: 3.0.0, 2.4.0
Reporter: Mit Desai
Assignee: Mit Desai
Labels: java7
Attachments: YARN-1883.patch
testRefreshUserToGroupsMappingsWithFileSystemBasedConfigurationProvider fails
with the following error:
{noformat}
java.lang.AssertionError: null
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at
org.apache.hadoop.yarn.server.resourcemanager.TestRMAdminService.testRefreshUserToGroupsMappingsWithFileSystemBasedConfigurationProvider(TestRMAdminService.java:421)
at
org.apache.hadoop.yarn.server.resourcemanager.TestRMAdminService.testOrder(TestRMAdminService.java:104)
{noformat}
Line Numbers will be inconsistent as I was testing to run it in a particular
order. But the Line on which the failure occurs is
{code}
Assert.assertTrue(groupBefore.contains(test_group_A)
groupBefore.contains(test_group_B)
groupBefore.contains(test_group_C) groupBefore.size() == 3);
{code}
testRMInitialsWithFileSystemBasedConfigurationProvider() and
testRefreshUserToGroupsMappingsWithFileSystemBasedConfigurationProvider()
calls the function {{MockUnixGroupsMapping.updateGroups();}} which changes
the list of userGroups.
testRefreshUserToGroupsMappingsWithFileSystemBasedConfigurationProvider()
tries to verify the groups before changing it and fails if
testRMInitialsWithFileSystemBasedConfigurationProvider() already ran and made
the changes.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (YARN-304) RM Tracking Links for purged applications needs a long-term solution
[ https://issues.apache.org/jira/browse/YARN-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mayank Bansal updated YARN-304: --- Attachment: YARN-304-1.patch Attaching patch Thanks, Mayank RM Tracking Links for purged applications needs a long-term solution Key: YARN-304 URL: https://issues.apache.org/jira/browse/YARN-304 Project: Hadoop YARN Issue Type: Sub-task Affects Versions: 3.0.0, 0.23.5 Reporter: Derek Dagit Assignee: Mayank Bansal Attachments: YARN-304-1.patch This JIRA is intended to track a proper long-term fix for the issue described in YARN-285. The following is from the original description: As applications complete, the RM tracks their IDs in a completed list. This list is routinely truncated to limit the total number of application remembered by the RM. When a user clicks the History for a job, either the browser is redirected to the application's tracking link obtained from the stored application instance. But when the application has been purged from the RM, an error is displayed. In very busy clusters the rate at which applications complete can cause applications to be purged from the RM's internal list within hours, which breaks the proxy URLs users have saved for their jobs. We would like the RM to provide valid tracking links persist so that users are not frustrated by broken links. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (YARN-1809) Synchronize RM and Generic History Service Web-UIs
[
https://issues.apache.org/jira/browse/YARN-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949097#comment-13949097
]
Hadoop QA commented on YARN-1809:
-
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12637101/YARN-1809.8.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 4 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. There were no new javadoc warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-api
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-common
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-applicationhistoryservice
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-common
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager.
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-YARN-Build/3471//testReport/
Console output: https://builds.apache.org/job/PreCommit-YARN-Build/3471//console
This message is automatically generated.
Synchronize RM and Generic History Service Web-UIs
--
Key: YARN-1809
URL: https://issues.apache.org/jira/browse/YARN-1809
Project: Hadoop YARN
Issue Type: Bug
Reporter: Zhijie Shen
Assignee: Zhijie Shen
Attachments: YARN-1809.1.patch, YARN-1809.2.patch, YARN-1809.3.patch,
YARN-1809.4.patch, YARN-1809.5.patch, YARN-1809.5.patch, YARN-1809.6.patch,
YARN-1809.7.patch, YARN-1809.8.patch
After YARN-953, the web-UI of generic history service is provide more
information than that of RM, the details about app attempt and container.
It's good to provide similar web-UIs, but retrieve the data from separate
source, i.e., RM cache and history store respectively.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (YARN-304) RM Tracking Links for purged applications needs a long-term solution
[
https://issues.apache.org/jira/browse/YARN-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949096#comment-13949096
]
Hadoop QA commented on YARN-304:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12637103/YARN-304-1.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. There were no new javadoc warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:red}-1 findbugs{color}. The patch appears to introduce 1 new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager.
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-YARN-Build/3472//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-YARN-Build/3472//artifact/trunk/patchprocess/newPatchFindbugsWarningshadoop-yarn-server-resourcemanager.html
Console output: https://builds.apache.org/job/PreCommit-YARN-Build/3472//console
This message is automatically generated.
RM Tracking Links for purged applications needs a long-term solution
Key: YARN-304
URL: https://issues.apache.org/jira/browse/YARN-304
Project: Hadoop YARN
Issue Type: Sub-task
Affects Versions: 3.0.0, 0.23.5
Reporter: Derek Dagit
Assignee: Mayank Bansal
Attachments: YARN-304-1.patch
This JIRA is intended to track a proper long-term fix for the issue described
in YARN-285.
The following is from the original description:
As applications complete, the RM tracks their IDs in a completed list. This
list is routinely truncated to limit the total number of application
remembered by the RM.
When a user clicks the History for a job, either the browser is redirected to
the application's tracking link obtained from the stored application
instance. But when the application has been purged from the RM, an error is
displayed.
In very busy clusters the rate at which applications complete can cause
applications to be purged from the RM's internal list within hours, which
breaks the proxy URLs users have saved for their jobs.
We would like the RM to provide valid tracking links persist so that users
are not frustrated by broken links.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (YARN-1873) TestDistributedShell#testDSShell fails when the test cases are out of order
[
https://issues.apache.org/jira/browse/YARN-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949175#comment-13949175
]
Hudson commented on YARN-1873:
--
SUCCESS: Integrated in Hadoop-Yarn-trunk #522 (See
[https://builds.apache.org/job/Hadoop-Yarn-trunk/522/])
YARN-1873. Fixed TestDistributedShell failure when the test cases are out of
order. Contributed by Mit Desai. (zjshen:
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1582060)
* /hadoop/common/trunk/hadoop-yarn-project/CHANGES.txt
*
/hadoop/common/trunk/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-distributedshell/src/test/java/org/apache/hadoop/yarn/applications/distributedshell/TestDistributedShell.java
TestDistributedShell#testDSShell fails when the test cases are out of order
---
Key: YARN-1873
URL: https://issues.apache.org/jira/browse/YARN-1873
Project: Hadoop YARN
Issue Type: Bug
Affects Versions: 3.0.0, 2.4.0
Reporter: Mit Desai
Assignee: Mit Desai
Labels: test
Fix For: 2.4.0
Attachments: YARN-1873.patch, YARN-1873.patch, YARN-1873.patch
testDSShell fails when the tests are run in random order. I see a cleanup
issue here.
{noformat}
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 72.222 sec
FAILURE! - in
org.apache.hadoop.yarn.applications.distributedshell.TestDistributedShell
testOrder(org.apache.hadoop.yarn.applications.distributedshell.TestDistributedShell)
Time elapsed: 44.127 sec FAILURE!
java.lang.AssertionError: expected:1 but was:6
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at
org.apache.hadoop.yarn.applications.distributedshell.TestDistributedShell.testDSShell(TestDistributedShell.java:204)
at
org.apache.hadoop.yarn.applications.distributedshell.TestDistributedShell.testOrder(TestDistributedShell.java:134)
Results :
Failed tests:
TestDistributedShell.testOrder:134-testDSShell:204 expected:1 but was:6
{noformat}
The Line numbers will be little deviated because I was trying to reproduce
the error by running the tests in specific order. But the Line that causes
the assert fail is {{Assert.assertEquals(1,
entitiesAttempts.getEntities().size());}}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (YARN-1873) TestDistributedShell#testDSShell fails when the test cases are out of order
[
https://issues.apache.org/jira/browse/YARN-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949327#comment-13949327
]
Hudson commented on YARN-1873:
--
FAILURE: Integrated in Hadoop-Mapreduce-trunk #1739 (See
[https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1739/])
YARN-1873. Fixed TestDistributedShell failure when the test cases are out of
order. Contributed by Mit Desai. (zjshen:
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1582060)
* /hadoop/common/trunk/hadoop-yarn-project/CHANGES.txt
*
/hadoop/common/trunk/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-distributedshell/src/test/java/org/apache/hadoop/yarn/applications/distributedshell/TestDistributedShell.java
TestDistributedShell#testDSShell fails when the test cases are out of order
---
Key: YARN-1873
URL: https://issues.apache.org/jira/browse/YARN-1873
Project: Hadoop YARN
Issue Type: Bug
Affects Versions: 3.0.0, 2.4.0
Reporter: Mit Desai
Assignee: Mit Desai
Labels: test
Fix For: 2.4.0
Attachments: YARN-1873.patch, YARN-1873.patch, YARN-1873.patch
testDSShell fails when the tests are run in random order. I see a cleanup
issue here.
{noformat}
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 72.222 sec
FAILURE! - in
org.apache.hadoop.yarn.applications.distributedshell.TestDistributedShell
testOrder(org.apache.hadoop.yarn.applications.distributedshell.TestDistributedShell)
Time elapsed: 44.127 sec FAILURE!
java.lang.AssertionError: expected:1 but was:6
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at
org.apache.hadoop.yarn.applications.distributedshell.TestDistributedShell.testDSShell(TestDistributedShell.java:204)
at
org.apache.hadoop.yarn.applications.distributedshell.TestDistributedShell.testOrder(TestDistributedShell.java:134)
Results :
Failed tests:
TestDistributedShell.testOrder:134-testDSShell:204 expected:1 but was:6
{noformat}
The Line numbers will be little deviated because I was trying to reproduce
the error by running the tests in specific order. But the Line that causes
the assert fail is {{Assert.assertEquals(1,
entitiesAttempts.getEntities().size());}}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (YARN-1883) TestRMAdminService fails due to inconsistent entries in UserGroups
[
https://issues.apache.org/jira/browse/YARN-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mit Desai updated YARN-1883:
Attachment: YARN-1883.patch
Thanks for looking into it [~ajisakaa].
Updated the fix
TestRMAdminService fails due to inconsistent entries in UserGroups
--
Key: YARN-1883
URL: https://issues.apache.org/jira/browse/YARN-1883
Project: Hadoop YARN
Issue Type: Bug
Affects Versions: 3.0.0, 2.4.0
Reporter: Mit Desai
Assignee: Mit Desai
Labels: java7
Attachments: YARN-1883.patch, YARN-1883.patch
testRefreshUserToGroupsMappingsWithFileSystemBasedConfigurationProvider fails
with the following error:
{noformat}
java.lang.AssertionError: null
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at
org.apache.hadoop.yarn.server.resourcemanager.TestRMAdminService.testRefreshUserToGroupsMappingsWithFileSystemBasedConfigurationProvider(TestRMAdminService.java:421)
at
org.apache.hadoop.yarn.server.resourcemanager.TestRMAdminService.testOrder(TestRMAdminService.java:104)
{noformat}
Line Numbers will be inconsistent as I was testing to run it in a particular
order. But the Line on which the failure occurs is
{code}
Assert.assertTrue(groupBefore.contains(test_group_A)
groupBefore.contains(test_group_B)
groupBefore.contains(test_group_C) groupBefore.size() == 3);
{code}
testRMInitialsWithFileSystemBasedConfigurationProvider() and
testRefreshUserToGroupsMappingsWithFileSystemBasedConfigurationProvider()
calls the function {{MockUnixGroupsMapping.updateGroups();}} which changes
the list of userGroups.
testRefreshUserToGroupsMappingsWithFileSystemBasedConfigurationProvider()
tries to verify the groups before changing it and fails if
testRMInitialsWithFileSystemBasedConfigurationProvider() already ran and made
the changes.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (YARN-1873) TestDistributedShell#testDSShell fails when the test cases are out of order
[
https://issues.apache.org/jira/browse/YARN-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949360#comment-13949360
]
Hudson commented on YARN-1873:
--
SUCCESS: Integrated in Hadoop-Hdfs-trunk #1714 (See
[https://builds.apache.org/job/Hadoop-Hdfs-trunk/1714/])
YARN-1873. Fixed TestDistributedShell failure when the test cases are out of
order. Contributed by Mit Desai. (zjshen:
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1582060)
* /hadoop/common/trunk/hadoop-yarn-project/CHANGES.txt
*
/hadoop/common/trunk/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-applications/hadoop-yarn-applications-distributedshell/src/test/java/org/apache/hadoop/yarn/applications/distributedshell/TestDistributedShell.java
TestDistributedShell#testDSShell fails when the test cases are out of order
---
Key: YARN-1873
URL: https://issues.apache.org/jira/browse/YARN-1873
Project: Hadoop YARN
Issue Type: Bug
Affects Versions: 3.0.0, 2.4.0
Reporter: Mit Desai
Assignee: Mit Desai
Labels: test
Fix For: 2.4.0
Attachments: YARN-1873.patch, YARN-1873.patch, YARN-1873.patch
testDSShell fails when the tests are run in random order. I see a cleanup
issue here.
{noformat}
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 72.222 sec
FAILURE! - in
org.apache.hadoop.yarn.applications.distributedshell.TestDistributedShell
testOrder(org.apache.hadoop.yarn.applications.distributedshell.TestDistributedShell)
Time elapsed: 44.127 sec FAILURE!
java.lang.AssertionError: expected:1 but was:6
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at
org.apache.hadoop.yarn.applications.distributedshell.TestDistributedShell.testDSShell(TestDistributedShell.java:204)
at
org.apache.hadoop.yarn.applications.distributedshell.TestDistributedShell.testOrder(TestDistributedShell.java:134)
Results :
Failed tests:
TestDistributedShell.testOrder:134-testDSShell:204 expected:1 but was:6
{noformat}
The Line numbers will be little deviated because I was trying to reproduce
the error by running the tests in specific order. But the Line that causes
the assert fail is {{Assert.assertEquals(1,
entitiesAttempts.getEntities().size());}}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (YARN-1883) TestRMAdminService fails due to inconsistent entries in UserGroups
[
https://issues.apache.org/jira/browse/YARN-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949420#comment-13949420
]
Hadoop QA commented on YARN-1883:
-
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12637149/YARN-1883.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. There were no new javadoc warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager.
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-YARN-Build/3473//testReport/
Console output: https://builds.apache.org/job/PreCommit-YARN-Build/3473//console
This message is automatically generated.
TestRMAdminService fails due to inconsistent entries in UserGroups
--
Key: YARN-1883
URL: https://issues.apache.org/jira/browse/YARN-1883
Project: Hadoop YARN
Issue Type: Bug
Affects Versions: 3.0.0, 2.4.0
Reporter: Mit Desai
Assignee: Mit Desai
Labels: java7
Attachments: YARN-1883.patch, YARN-1883.patch
testRefreshUserToGroupsMappingsWithFileSystemBasedConfigurationProvider fails
with the following error:
{noformat}
java.lang.AssertionError: null
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at
org.apache.hadoop.yarn.server.resourcemanager.TestRMAdminService.testRefreshUserToGroupsMappingsWithFileSystemBasedConfigurationProvider(TestRMAdminService.java:421)
at
org.apache.hadoop.yarn.server.resourcemanager.TestRMAdminService.testOrder(TestRMAdminService.java:104)
{noformat}
Line Numbers will be inconsistent as I was testing to run it in a particular
order. But the Line on which the failure occurs is
{code}
Assert.assertTrue(groupBefore.contains(test_group_A)
groupBefore.contains(test_group_B)
groupBefore.contains(test_group_C) groupBefore.size() == 3);
{code}
testRMInitialsWithFileSystemBasedConfigurationProvider() and
testRefreshUserToGroupsMappingsWithFileSystemBasedConfigurationProvider()
calls the function {{MockUnixGroupsMapping.updateGroups();}} which changes
the list of userGroups.
testRefreshUserToGroupsMappingsWithFileSystemBasedConfigurationProvider()
tries to verify the groups before changing it and fails if
testRMInitialsWithFileSystemBasedConfigurationProvider() already ran and made
the changes.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (YARN-1883) TestRMAdminService fails due to inconsistent entries in UserGroups
[
https://issues.apache.org/jira/browse/YARN-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949443#comment-13949443
]
Akira AJISAKA commented on YARN-1883:
-
LGTM, +1.
TestRMAdminService fails due to inconsistent entries in UserGroups
--
Key: YARN-1883
URL: https://issues.apache.org/jira/browse/YARN-1883
Project: Hadoop YARN
Issue Type: Bug
Affects Versions: 3.0.0, 2.4.0
Reporter: Mit Desai
Assignee: Mit Desai
Labels: java7
Attachments: YARN-1883.patch, YARN-1883.patch
testRefreshUserToGroupsMappingsWithFileSystemBasedConfigurationProvider fails
with the following error:
{noformat}
java.lang.AssertionError: null
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at
org.apache.hadoop.yarn.server.resourcemanager.TestRMAdminService.testRefreshUserToGroupsMappingsWithFileSystemBasedConfigurationProvider(TestRMAdminService.java:421)
at
org.apache.hadoop.yarn.server.resourcemanager.TestRMAdminService.testOrder(TestRMAdminService.java:104)
{noformat}
Line Numbers will be inconsistent as I was testing to run it in a particular
order. But the Line on which the failure occurs is
{code}
Assert.assertTrue(groupBefore.contains(test_group_A)
groupBefore.contains(test_group_B)
groupBefore.contains(test_group_C) groupBefore.size() == 3);
{code}
testRMInitialsWithFileSystemBasedConfigurationProvider() and
testRefreshUserToGroupsMappingsWithFileSystemBasedConfigurationProvider()
calls the function {{MockUnixGroupsMapping.updateGroups();}} which changes
the list of userGroups.
testRefreshUserToGroupsMappingsWithFileSystemBasedConfigurationProvider()
tries to verify the groups before changing it and fails if
testRMInitialsWithFileSystemBasedConfigurationProvider() already ran and made
the changes.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (YARN-1883) TestRMAdminService fails due to inconsistent entries in UserGroups
[
https://issues.apache.org/jira/browse/YARN-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akira AJISAKA updated YARN-1883:
Hadoop Flags: Reviewed
TestRMAdminService fails due to inconsistent entries in UserGroups
--
Key: YARN-1883
URL: https://issues.apache.org/jira/browse/YARN-1883
Project: Hadoop YARN
Issue Type: Bug
Affects Versions: 3.0.0, 2.4.0
Reporter: Mit Desai
Assignee: Mit Desai
Labels: java7
Attachments: YARN-1883.patch, YARN-1883.patch
testRefreshUserToGroupsMappingsWithFileSystemBasedConfigurationProvider fails
with the following error:
{noformat}
java.lang.AssertionError: null
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at
org.apache.hadoop.yarn.server.resourcemanager.TestRMAdminService.testRefreshUserToGroupsMappingsWithFileSystemBasedConfigurationProvider(TestRMAdminService.java:421)
at
org.apache.hadoop.yarn.server.resourcemanager.TestRMAdminService.testOrder(TestRMAdminService.java:104)
{noformat}
Line Numbers will be inconsistent as I was testing to run it in a particular
order. But the Line on which the failure occurs is
{code}
Assert.assertTrue(groupBefore.contains(test_group_A)
groupBefore.contains(test_group_B)
groupBefore.contains(test_group_C) groupBefore.size() == 3);
{code}
testRMInitialsWithFileSystemBasedConfigurationProvider() and
testRefreshUserToGroupsMappingsWithFileSystemBasedConfigurationProvider()
calls the function {{MockUnixGroupsMapping.updateGroups();}} which changes
the list of userGroups.
testRefreshUserToGroupsMappingsWithFileSystemBasedConfigurationProvider()
tries to verify the groups before changing it and fails if
testRMInitialsWithFileSystemBasedConfigurationProvider() already ran and made
the changes.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (YARN-596) In fair scheduler, intra-application container priorities affect inter-application preemption decisions
[
https://issues.apache.org/jira/browse/YARN-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13949522#comment-13949522
]
Hadoop QA commented on YARN-596:
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12637163/YARN-596.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. There were no new javadoc warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager.
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-YARN-Build/3474//testReport/
Console output: https://builds.apache.org/job/PreCommit-YARN-Build/3474//console
This message is automatically generated.
In fair scheduler, intra-application container priorities affect
inter-application preemption decisions
---
Key: YARN-596
URL: https://issues.apache.org/jira/browse/YARN-596
Project: Hadoop YARN
Issue Type: Bug
Components: scheduler
Affects Versions: 2.0.3-alpha
Reporter: Sandy Ryza
Assignee: Sandy Ryza
Attachments: YARN-596.patch, YARN-596.patch, YARN-596.patch,
YARN-596.patch
In the fair scheduler, containers are chosen for preemption in the following
way:
All containers for all apps that are in queues that are over their fair share
are put in a list.
The list is sorted in order of the priority that the container was requested
in.
This means that an application can shield itself from preemption by
requesting it's containers at higher priorities, which doesn't really make
sense.
Also, an application that is not over its fair share, but that is in a queue
that is over it's fair share is just as likely to have containers preempted
as an application that is over its fair share.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (YARN-1809) Synchronize RM and Generic History Service Web-UIs
[ https://issues.apache.org/jira/browse/YARN-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhijie Shen updated YARN-1809: -- Issue Type: Improvement (was: Bug) Synchronize RM and Generic History Service Web-UIs -- Key: YARN-1809 URL: https://issues.apache.org/jira/browse/YARN-1809 Project: Hadoop YARN Issue Type: Improvement Reporter: Zhijie Shen Assignee: Zhijie Shen Attachments: YARN-1809.1.patch, YARN-1809.2.patch, YARN-1809.3.patch, YARN-1809.4.patch, YARN-1809.5.patch, YARN-1809.5.patch, YARN-1809.6.patch, YARN-1809.7.patch, YARN-1809.8.patch After YARN-953, the web-UI of generic history service is provide more information than that of RM, the details about app attempt and container. It's good to provide similar web-UIs, but retrieve the data from separate source, i.e., RM cache and history store respectively. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (YARN-1817) Synchronize RM and Generic History Service RESTful Web Services
[ https://issues.apache.org/jira/browse/YARN-1817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhijie Shen updated YARN-1817: -- Issue Type: Improvement (was: Bug) Synchronize RM and Generic History Service RESTful Web Services --- Key: YARN-1817 URL: https://issues.apache.org/jira/browse/YARN-1817 Project: Hadoop YARN Issue Type: Improvement Reporter: Zhijie Shen Assignee: Zhijie Shen RMWebServices and AHSWebServices has a bunch of duplicate code at getApps/getApp/getAppAttempts. We need to reuse the logic RMWebServices, but retrieve the application information from different data source respectively. In addition, RMWebServices needs to provide getAppAttempt/getContainers/getContainer as well, as AHSWebServices has already exposed them. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (YARN-1885) yarn logs command does not provide the application logs for some applications
Arpit Gupta created YARN-1885: - Summary: yarn logs command does not provide the application logs for some applications Key: YARN-1885 URL: https://issues.apache.org/jira/browse/YARN-1885 Project: Hadoop YARN Issue Type: Bug Affects Versions: 2.4.0 Reporter: Arpit Gupta During our testing we have seen cases where yarn application logs are not available through the cli but i can look at AM logs through the UI. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (YARN-1426) YARN Components need to unregister their beans upon shutdown
[ https://issues.apache.org/jira/browse/YARN-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Eagles updated YARN-1426: -- Attachment: YARN-1426.patch YARN Components need to unregister their beans upon shutdown Key: YARN-1426 URL: https://issues.apache.org/jira/browse/YARN-1426 Project: Hadoop YARN Issue Type: Improvement Affects Versions: 3.0.0, 2.3.0 Reporter: Jonathan Eagles Assignee: Jonathan Eagles Attachments: YARN-1426.patch, YARN-1426.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (YARN-1106) The RM should point the tracking url to the RM app page if its empty
[ https://issues.apache.org/jira/browse/YARN-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Eagles updated YARN-1106: -- Attachment: YARN-1106.patch [~tgraves]. I tried the latest patch against trunk but the tests now fail since the originalTrackingUrl is set to N/A and not null or empty. If we still want this behavior, we will need to add this condition as well. The RM should point the tracking url to the RM app page if its empty Key: YARN-1106 URL: https://issues.apache.org/jira/browse/YARN-1106 Project: Hadoop YARN Issue Type: Bug Components: resourcemanager Affects Versions: 3.0.0, 2.1.0-beta, 0.23.9 Reporter: Thomas Graves Assignee: Thomas Graves Attachments: YARN-1106.patch, YARN-1106.patch It would be nice if the Resourcemanager set the tracking url to the RM app page if the application master doesn't pass one or passes the empty string. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (YARN-1876) Document the REST APIs of timeline and generic history services
[ https://issues.apache.org/jira/browse/YARN-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhijie Shen updated YARN-1876: -- Attachment: YARN-1876.3.patch Fix one sentence Document the REST APIs of timeline and generic history services --- Key: YARN-1876 URL: https://issues.apache.org/jira/browse/YARN-1876 Project: Hadoop YARN Issue Type: Improvement Reporter: Zhijie Shen Assignee: Zhijie Shen Labels: documentaion Attachments: YARN-1876.1.patch, YARN-1876.2.patch, YARN-1876.3.patch -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (YARN-1886) Exceptions in the RM log while cleaning up app attempt
Arpit Gupta created YARN-1886: - Summary: Exceptions in the RM log while cleaning up app attempt Key: YARN-1886 URL: https://issues.apache.org/jira/browse/YARN-1886 Project: Hadoop YARN Issue Type: Bug Affects Versions: 2.4.0 Reporter: Arpit Gupta Noticed exceptions in the RM log while HA tests were running where we killed RM/AM/Namnode etc. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (YARN-1886) Exceptions in the RM log while cleaning up app attempt
[
https://issues.apache.org/jira/browse/YARN-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950027#comment-13950027
]
Arpit Gupta commented on YARN-1886:
---
{code}
2014-03-27 10:20:24,728 INFO capacity.CapacityScheduler
(CapacityScheduler.java:doneApplicationAttempt(604)) - Unknown application
appattempt_1395915220380_0001_02 has completed!
2014-03-27 10:20:24,731 INFO recovery.RMStateStore
(RMStateStore.java:handleStoreEvent(620)) - Storing info for app:
application_1395915220380_0001
2014-03-27 10:20:24,733 INFO amlauncher.AMLauncher (AMLauncher.java:run(262))
- Cleaning master appattempt_1395915220380_0001_02
2014-03-27 10:20:24,778 WARN ipc.Client (Client.java:run(672)) - Exception
encountered while connecting to the server :
org.apache.hadoop.ipc.RemoteException(javax.security.sasl.SaslException):
DIGEST-MD5: digest response format violation. Mismatched response.
2014-03-27 10:20:24,780 INFO amlauncher.AMLauncher (AMLauncher.java:run(265))
- Error cleaning master
javax.security.sasl.SaslException: DIGEST-MD5: digest response format
violation. Mismatched response. [Caused by
org.apache.hadoop.ipc.RemoteException(javax.security.sasl.SaslException):
DIGEST-MD5: digest response format violation. Mismatched response.]
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at
org.apache.hadoop.yarn.ipc.RPCUtil.instantiateException(RPCUtil.java:53)
at
org.apache.hadoop.yarn.ipc.RPCUtil.unwrapAndThrowException(RPCUtil.java:104)
at
org.apache.hadoop.yarn.api.impl.pb.client.ContainerManagementProtocolPBClientImpl.stopContainers(ContainerManagementProtocolPBClientImpl.java:113)
at
org.apache.hadoop.yarn.server.resourcemanager.amlauncher.AMLauncher.cleanup(AMLauncher.java:138)
at
org.apache.hadoop.yarn.server.resourcemanager.amlauncher.AMLauncher.run(AMLauncher.java:263)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by:
org.apache.hadoop.ipc.RemoteException(javax.security.sasl.SaslException):
DIGEST-MD5: digest response format violation. Mismatched response.
at org.apache.hadoop.ipc.Client.call(Client.java:1410)
at org.apache.hadoop.ipc.Client.call(Client.java:1363)
at
org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:206)
at $Proxy35.stopContainers(Unknown Source)
at
org.apache.hadoop.yarn.api.impl.pb.client.ContainerManagementProtocolPBClientImpl.stopContainers(ContainerManagementProtocolPBClientImpl.java:110)
... 5 more
2014-03-27 10:20:24,794 INFO recovery.ZKRMStateStore
(ZKRMStateStore.java:processWatchEvent(778)) - Watcher event type:
NodeDataChanged with state:SyncConnected for
path:/rmstore/ZKRMStateRoot/RMAppRoot/application_1395915220380_0001 for
Service org.apache.hadoop.yarn.server.resourcemanager.recovery.RMStateStore in
state org.apache.hadoop.yarn.server.resourcemanager.recovery.RMStateStore:
STARTED
{code}
Exceptions in the RM log while cleaning up app attempt
--
Key: YARN-1886
URL: https://issues.apache.org/jira/browse/YARN-1886
Project: Hadoop YARN
Issue Type: Bug
Affects Versions: 2.4.0
Reporter: Arpit Gupta
Noticed exceptions in the RM log while HA tests were running where we killed
RM/AM/Namnode etc.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (YARN-1886) Exceptions in the RM log while cleaning up app attempt
[ https://issues.apache.org/jira/browse/YARN-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arpit Gupta updated YARN-1886: -- Description: Noticed exceptions in the RM log while HA tests were running where we killed RM/AM/Namnode etc. RM failed over and the new active RM tried to kill the old app attempt and ran into this exception. was:Noticed exceptions in the RM log while HA tests were running where we killed RM/AM/Namnode etc. Exceptions in the RM log while cleaning up app attempt -- Key: YARN-1886 URL: https://issues.apache.org/jira/browse/YARN-1886 Project: Hadoop YARN Issue Type: Bug Affects Versions: 2.4.0 Reporter: Arpit Gupta Noticed exceptions in the RM log while HA tests were running where we killed RM/AM/Namnode etc. RM failed over and the new active RM tried to kill the old app attempt and ran into this exception. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (YARN-1106) The RM should point the tracking url to the RM app page if its empty
[
https://issues.apache.org/jira/browse/YARN-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950042#comment-13950042
]
Zhijie Shen commented on YARN-1106:
---
bq. since the originalTrackingUrl is set to N/A
There's a related bug that we've seen before. Since originalTrackingUrl is set
to N/A when registration and unregistration doesn't supply a tracking url.
When generating proxiedTrackingUrl, generateProxyUriWithScheme is called with
N/A as input
{code}
final String scheme = WebAppUtils.getHttpSchemePrefix(conf);
URI trackingUri = StringUtils.isEmpty(trackingUriWithoutScheme) ? null :
ProxyUriUtils.getUriFromAMUrl(scheme, trackingUriWithoutScheme);
String proxy = WebAppUtils.getProxyHostAndPort(conf);
URI proxyUri = ProxyUriUtils.getUriFromAMUrl(scheme, proxy);
URI result = ProxyUriUtils.getProxyUri(trackingUri, proxyUri,
applicationAttemptId.getApplicationId());
{code}
Int generateProxyUriWithScheme, trackingUri will be set to http://N/A;, and
result will be set to a wrong string, such as
http://proxy.net:8080/proxy/application_1234567_0001/*A*;.
The RM should point the tracking url to the RM app page if its empty
Key: YARN-1106
URL: https://issues.apache.org/jira/browse/YARN-1106
Project: Hadoop YARN
Issue Type: Bug
Components: resourcemanager
Affects Versions: 3.0.0, 2.1.0-beta, 0.23.9
Reporter: Thomas Graves
Assignee: Thomas Graves
Attachments: YARN-1106.patch, YARN-1106.patch
It would be nice if the Resourcemanager set the tracking url to the RM app
page if the application master doesn't pass one or passes the empty string.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (YARN-1106) The RM should point the tracking url to the RM app page if its empty
[
https://issues.apache.org/jira/browse/YARN-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950061#comment-13950061
]
Hadoop QA commented on YARN-1106:
-
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12637253/YARN-1106.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. There were no new javadoc warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The patch failed these unit tests in
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager:
org.apache.hadoop.yarn.server.resourcemanager.rmapp.TestRMAppTransitions
org.apache.hadoop.yarn.server.resourcemanager.rmapp.attempt.TestRMAppAttemptTransitions
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-YARN-Build/3476//testReport/
Console output: https://builds.apache.org/job/PreCommit-YARN-Build/3476//console
This message is automatically generated.
The RM should point the tracking url to the RM app page if its empty
Key: YARN-1106
URL: https://issues.apache.org/jira/browse/YARN-1106
Project: Hadoop YARN
Issue Type: Bug
Components: resourcemanager
Affects Versions: 3.0.0, 2.1.0-beta, 0.23.9
Reporter: Thomas Graves
Assignee: Thomas Graves
Attachments: YARN-1106.patch, YARN-1106.patch
It would be nice if the Resourcemanager set the tracking url to the RM app
page if the application master doesn't pass one or passes the empty string.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (YARN-1876) Document the REST APIs of timeline and generic history services
[
https://issues.apache.org/jira/browse/YARN-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950081#comment-13950081
]
Hadoop QA commented on YARN-1876:
-
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12637256/YARN-1876.3.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. There were no new javadoc warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in .
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-YARN-Build/3477//testReport/
Console output: https://builds.apache.org/job/PreCommit-YARN-Build/3477//console
This message is automatically generated.
Document the REST APIs of timeline and generic history services
---
Key: YARN-1876
URL: https://issues.apache.org/jira/browse/YARN-1876
Project: Hadoop YARN
Issue Type: Improvement
Reporter: Zhijie Shen
Assignee: Zhijie Shen
Labels: documentaion
Attachments: YARN-1876.1.patch, YARN-1876.2.patch, YARN-1876.3.patch
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (YARN-1426) YARN Components need to unregister their beans upon shutdown
[
https://issues.apache.org/jira/browse/YARN-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950107#comment-13950107
]
Hadoop QA commented on YARN-1426:
-
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12637242/YARN-1426.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. There were no new javadoc warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager.
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-YARN-Build/3475//testReport/
Console output: https://builds.apache.org/job/PreCommit-YARN-Build/3475//console
This message is automatically generated.
YARN Components need to unregister their beans upon shutdown
Key: YARN-1426
URL: https://issues.apache.org/jira/browse/YARN-1426
Project: Hadoop YARN
Issue Type: Improvement
Affects Versions: 3.0.0, 2.3.0
Reporter: Jonathan Eagles
Assignee: Jonathan Eagles
Attachments: YARN-1426.patch, YARN-1426.patch
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (YARN-1874) Cleanup: Move RMActiveServices out of ResourceManager into its own file
[ https://issues.apache.org/jira/browse/YARN-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tsuyoshi OZAWA updated YARN-1874: - Attachment: YARN-1874.1.patch Moved RMActiveServices out to a file and fixed some tests to work. Cleanup: Move RMActiveServices out of ResourceManager into its own file --- Key: YARN-1874 URL: https://issues.apache.org/jira/browse/YARN-1874 Project: Hadoop YARN Issue Type: Bug Components: resourcemanager Reporter: Karthik Kambatla Assignee: Tsuyoshi OZAWA Attachments: YARN-1874.1.patch As [~vinodkv] noticed on YARN-1867, ResourceManager is hard to maintain. We should move RMActiveServices out to make it more manageable. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (YARN-1474) Make schedulers services
[ https://issues.apache.org/jira/browse/YARN-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950162#comment-13950162 ] Tsuyoshi OZAWA commented on YARN-1474: -- Karthik, thanks you for the comment. I'll fix the findbugs warnings soon. +1 for committing this to only branch-2, because 2.4 release is coming. Make schedulers services Key: YARN-1474 URL: https://issues.apache.org/jira/browse/YARN-1474 Project: Hadoop YARN Issue Type: Sub-task Components: scheduler Affects Versions: 2.3.0 Reporter: Sandy Ryza Assignee: Tsuyoshi OZAWA Attachments: YARN-1474.1.patch, YARN-1474.2.patch, YARN-1474.3.patch, YARN-1474.4.patch, YARN-1474.5.patch, YARN-1474.6.patch, YARN-1474.7.patch Schedulers currently have a reinitialize but no start and stop. Fitting them into the YARN service model would make things more coherent. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (YARN-1874) Cleanup: Move RMActiveServices out of ResourceManager into its own file
[ https://issues.apache.org/jira/browse/YARN-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950167#comment-13950167 ] Tsuyoshi OZAWA commented on YARN-1874: -- Maybe should we do this after YARN-1474? Cleanup: Move RMActiveServices out of ResourceManager into its own file --- Key: YARN-1874 URL: https://issues.apache.org/jira/browse/YARN-1874 Project: Hadoop YARN Issue Type: Bug Components: resourcemanager Reporter: Karthik Kambatla Assignee: Tsuyoshi OZAWA Attachments: YARN-1874.1.patch As [~vinodkv] noticed on YARN-1867, ResourceManager is hard to maintain. We should move RMActiveServices out to make it more manageable. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (YARN-1874) Cleanup: Move RMActiveServices out of ResourceManager into its own file
[
https://issues.apache.org/jira/browse/YARN-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950226#comment-13950226
]
Hadoop QA commented on YARN-1874:
-
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12637290/YARN-1874.1.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 18 new
or modified test files.
{color:red}-1 javac{color}. The applied patch generated 1490 javac
compiler warnings (more than the trunk's current 1489 warnings).
{color:green}+1 javadoc{color}. There were no new javadoc warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 core tests{color}. The patch failed these unit tests in
hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-client
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager:
org.apache.hadoop.mapreduce.v2.app.TestMRAppMaster
org.apache.hadoop.mapreduce.v2.app.TestRMContainerAllocator
org.apache.hadoop.yarn.client.TestResourceTrackerOnHA
org.apache.hadoop.yarn.server.resourcemanager.TestClientRMService
org.apache.hadoop.yarn.server.resourcemanager.security.TestAMRMTokens
org.apache.hadoop.yarn.server.resourcemanager.TestAMAuthorization
org.apache.hadoop.yarn.server.resourcemanager.scheduler.TestSchedulerUtils
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-YARN-Build/3478//testReport/
Javac warnings:
https://builds.apache.org/job/PreCommit-YARN-Build/3478//artifact/trunk/patchprocess/diffJavacWarnings.txt
Console output: https://builds.apache.org/job/PreCommit-YARN-Build/3478//console
This message is automatically generated.
Cleanup: Move RMActiveServices out of ResourceManager into its own file
---
Key: YARN-1874
URL: https://issues.apache.org/jira/browse/YARN-1874
Project: Hadoop YARN
Issue Type: Bug
Components: resourcemanager
Reporter: Karthik Kambatla
Assignee: Tsuyoshi OZAWA
Attachments: YARN-1874.1.patch
As [~vinodkv] noticed on YARN-1867, ResourceManager is hard to maintain. We
should move RMActiveServices out to make it more manageable.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (YARN-1809) Synchronize RM and Generic History Service Web-UIs
[ https://issues.apache.org/jira/browse/YARN-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhijie Shen updated YARN-1809: -- Attachment: YARN-1809.9.patch Talked to Vinod offline about the patch and made following changes in the new one: 1. Mark ApplicationBaseProtocol \@Private 2. Mark ApplicationHistoryManager \@Private 3. Revert the hack code for FairSchedulerAppsBlock, and I just simply duplicate most code of AppsBlock, as the old FairSchedulerAppsBlock duplicates the old AppsBlock. I'll file a separate Jira to tackle the refactoring of FairSchedulerAppsBlock. Synchronize RM and Generic History Service Web-UIs -- Key: YARN-1809 URL: https://issues.apache.org/jira/browse/YARN-1809 Project: Hadoop YARN Issue Type: Improvement Reporter: Zhijie Shen Assignee: Zhijie Shen Attachments: YARN-1809.1.patch, YARN-1809.2.patch, YARN-1809.3.patch, YARN-1809.4.patch, YARN-1809.5.patch, YARN-1809.5.patch, YARN-1809.6.patch, YARN-1809.7.patch, YARN-1809.8.patch, YARN-1809.9.patch After YARN-953, the web-UI of generic history service is provide more information than that of RM, the details about app attempt and container. It's good to provide similar web-UIs, but retrieve the data from separate source, i.e., RM cache and history store respectively. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (YARN-1887) FairSchedulerAppsBlock and AppsBlock duplicate much code
Zhijie Shen created YARN-1887: - Summary: FairSchedulerAppsBlock and AppsBlock duplicate much code Key: YARN-1887 URL: https://issues.apache.org/jira/browse/YARN-1887 Project: Hadoop YARN Issue Type: Bug Reporter: Zhijie Shen Either now or after YARN-1809, FairSchedulerAppsBlock and AppsBlock duplicate much code. Ideally, FairSchedulerAppsBlock should extends AppsBlock to reuse most code, and override the method of creating app table headers and rows -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (YARN-1887) FairSchedulerAppsBlock and AppsBlock duplicate much code
[ https://issues.apache.org/jira/browse/YARN-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tsuyoshi OZAWA reassigned YARN-1887: Assignee: Tsuyoshi OZAWA FairSchedulerAppsBlock and AppsBlock duplicate much code Key: YARN-1887 URL: https://issues.apache.org/jira/browse/YARN-1887 Project: Hadoop YARN Issue Type: Bug Reporter: Zhijie Shen Assignee: Tsuyoshi OZAWA Either now or after YARN-1809, FairSchedulerAppsBlock and AppsBlock duplicate much code. Ideally, FairSchedulerAppsBlock should extends AppsBlock to reuse most code, and override the method of creating app table headers and rows -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (YARN-1885) yarn logs command does not provide the application logs for some applications
[ https://issues.apache.org/jira/browse/YARN-1885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950342#comment-13950342 ] Rohith commented on YARN-1885: -- [~arpitgupta] can you please describe more on the issue. 1. What is console output log says when yarn logs executed. 2. bq. i can look at AM logs through the UI Is it while application running or after application finished..? yarn logs command does not provide the application logs for some applications - Key: YARN-1885 URL: https://issues.apache.org/jira/browse/YARN-1885 Project: Hadoop YARN Issue Type: Bug Affects Versions: 2.4.0 Reporter: Arpit Gupta During our HA testing we have seen cases where yarn application logs are not available through the cli but i can look at AM logs through the UI. RM was also being restarted in the background as the application was running. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (YARN-1887) FairSchedulerAppsBlock and AppsBlock duplicate much code
[ https://issues.apache.org/jira/browse/YARN-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tsuyoshi OZAWA updated YARN-1887: - Attachment: YARN-1887.1.patch FairSchedulerAppsBlock and AppsBlock duplicate much code Key: YARN-1887 URL: https://issues.apache.org/jira/browse/YARN-1887 Project: Hadoop YARN Issue Type: Bug Reporter: Zhijie Shen Assignee: Tsuyoshi OZAWA Attachments: YARN-1887.1.patch Either now or after YARN-1809, FairSchedulerAppsBlock and AppsBlock duplicate much code. Ideally, FairSchedulerAppsBlock should extends AppsBlock to reuse most code, and override the method of creating app table headers and rows -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (YARN-1887) FairSchedulerAppsBlock and AppsBlock duplicate much code
[ https://issues.apache.org/jira/browse/YARN-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950364#comment-13950364 ] Tsuyoshi OZAWA commented on YARN-1887: -- Overview of changes: 1. AppBlock has 3 methods: rencer(), getTBocy(), and getAppsTableData(). render() callbacks getTBody() and getAppsTableData(). 2. FairSchedulerAppsBlock overrides getTBody() and getAppsTableData(). FairSchedulerAppsBlock and AppsBlock duplicate much code Key: YARN-1887 URL: https://issues.apache.org/jira/browse/YARN-1887 Project: Hadoop YARN Issue Type: Bug Reporter: Zhijie Shen Assignee: Tsuyoshi OZAWA Attachments: YARN-1887.1.patch Either now or after YARN-1809, FairSchedulerAppsBlock and AppsBlock duplicate much code. Ideally, FairSchedulerAppsBlock should extends AppsBlock to reuse most code, and override the method of creating app table headers and rows -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (YARN-1809) Synchronize RM and Generic History Service Web-UIs
[
https://issues.apache.org/jira/browse/YARN-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950366#comment-13950366
]
Hadoop QA commented on YARN-1809:
-
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12637324/YARN-1809.9.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 4 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. There were no new javadoc warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-api
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-common
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-applicationhistoryservice
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-common
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager.
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-YARN-Build/3479//testReport/
Console output: https://builds.apache.org/job/PreCommit-YARN-Build/3479//console
This message is automatically generated.
Synchronize RM and Generic History Service Web-UIs
--
Key: YARN-1809
URL: https://issues.apache.org/jira/browse/YARN-1809
Project: Hadoop YARN
Issue Type: Improvement
Reporter: Zhijie Shen
Assignee: Zhijie Shen
Attachments: YARN-1809.1.patch, YARN-1809.2.patch, YARN-1809.3.patch,
YARN-1809.4.patch, YARN-1809.5.patch, YARN-1809.5.patch, YARN-1809.6.patch,
YARN-1809.7.patch, YARN-1809.8.patch, YARN-1809.9.patch
After YARN-953, the web-UI of generic history service is provide more
information than that of RM, the details about app attempt and container.
It's good to provide similar web-UIs, but retrieve the data from separate
source, i.e., RM cache and history store respectively.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (YARN-1887) FairSchedulerAppsBlock and AppsBlock duplicate much code
[ https://issues.apache.org/jira/browse/YARN-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950369#comment-13950369 ] Zhijie Shen commented on YARN-1887: --- Hi [~ozawa], thanks for taking this ticket, but would you mind waiting until YARN-1809 is done? FairSchedulerAppsBlock and AppsBlock duplicate much code Key: YARN-1887 URL: https://issues.apache.org/jira/browse/YARN-1887 Project: Hadoop YARN Issue Type: Bug Reporter: Zhijie Shen Assignee: Tsuyoshi OZAWA Attachments: YARN-1887.1.patch Either now or after YARN-1809, FairSchedulerAppsBlock and AppsBlock duplicate much code. Ideally, FairSchedulerAppsBlock should extends AppsBlock to reuse most code, and override the method of creating app table headers and rows -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (YARN-1887) FairSchedulerAppsBlock and AppsBlock duplicate much code
[ https://issues.apache.org/jira/browse/YARN-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950372#comment-13950372 ] Tsuyoshi OZAWA commented on YARN-1887: -- Sure, no problem. FairSchedulerAppsBlock and AppsBlock duplicate much code Key: YARN-1887 URL: https://issues.apache.org/jira/browse/YARN-1887 Project: Hadoop YARN Issue Type: Bug Reporter: Zhijie Shen Assignee: Tsuyoshi OZAWA Attachments: YARN-1887.1.patch Either now or after YARN-1809, FairSchedulerAppsBlock and AppsBlock duplicate much code. Ideally, FairSchedulerAppsBlock should extends AppsBlock to reuse most code, and override the method of creating app table headers and rows -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (YARN-1474) Make schedulers services
[ https://issues.apache.org/jira/browse/YARN-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tsuyoshi OZAWA updated YARN-1474: - Attachment: YARN-1474.8.patch Fixed warning about synchronization. Make schedulers services Key: YARN-1474 URL: https://issues.apache.org/jira/browse/YARN-1474 Project: Hadoop YARN Issue Type: Sub-task Components: scheduler Affects Versions: 2.3.0 Reporter: Sandy Ryza Assignee: Tsuyoshi OZAWA Attachments: YARN-1474.1.patch, YARN-1474.2.patch, YARN-1474.3.patch, YARN-1474.4.patch, YARN-1474.5.patch, YARN-1474.6.patch, YARN-1474.7.patch, YARN-1474.8.patch Schedulers currently have a reinitialize but no start and stop. Fitting them into the YARN service model would make things more coherent. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (YARN-1869) Access to zkAcl should be synchronized in ZKRMStateStore#addStoreOrUpdateOps()
[
https://issues.apache.org/jira/browse/YARN-1869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950384#comment-13950384
]
Blue Arrow commented on YARN-1869:
--
Shorter duration locks are good as a general principle for performance but do
we know if the difference is worth worrying about in this case? One nice thing
about the method being synchronized is that it makes the synchronization clear
and visible when future code changes are made, which is always a plus when
working with concurrency. (It does leave the possibility of deadlocks via
external references versus synchronizing using a private). If we want to
implement a shorter duration lock, we should make that consistent by modifying
the other methods that are accessing zkAcl? Do we know if access/manipulation
of zkAcl is the only critical section in these methods? Thoughts?
Access to zkAcl should be synchronized in ZKRMStateStore#addStoreOrUpdateOps()
--
Key: YARN-1869
URL: https://issues.apache.org/jira/browse/YARN-1869
Project: Hadoop YARN
Issue Type: Bug
Reporter: Ted Yu
Priority: Minor
Attachments: yarn-1869.patch
Here is related code:
{code}
} else {
opList.add(Op.create(nodeCreatePath, tokenOs.toByteArray(), zkAcl,
CreateMode.PERSISTENT));
}
{code}
The other methods accessing zkAcl are synchronized.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (YARN-1887) FairSchedulerAppsBlock and AppsBlock duplicate much code
[
https://issues.apache.org/jira/browse/YARN-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13950391#comment-13950391
]
Hadoop QA commented on YARN-1887:
-
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12637331/YARN-1887.1.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. There were no new javadoc warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager.
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-YARN-Build/3480//testReport/
Console output: https://builds.apache.org/job/PreCommit-YARN-Build/3480//console
This message is automatically generated.
FairSchedulerAppsBlock and AppsBlock duplicate much code
Key: YARN-1887
URL: https://issues.apache.org/jira/browse/YARN-1887
Project: Hadoop YARN
Issue Type: Bug
Reporter: Zhijie Shen
Assignee: Tsuyoshi OZAWA
Attachments: YARN-1887.1.patch
Either now or after YARN-1809, FairSchedulerAppsBlock and AppsBlock duplicate
much code. Ideally, FairSchedulerAppsBlock should extends AppsBlock to reuse
most code, and override the method of creating app table headers and rows
--
This message was sent by Atlassian JIRA
(v6.2#6252)
