[jira] [Updated] (YARN-1144) Unmanaged AMs registering a tracking URI should not be proxy-fied
[
https://issues.apache.org/jira/browse/YARN-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alejandro Abdelnur updated YARN-1144:
-
Attachment: YARN-1144.patch
new patch fixing failure in
{{TestRMAppAttemptTransitions.testUnmanagedAMSuccess}} which was expecting a
proxied URL for unmanaged AM
Unmanaged AMs registering a tracking URI should not be proxy-fied
-
Key: YARN-1144
URL: https://issues.apache.org/jira/browse/YARN-1144
Project: Hadoop YARN
Issue Type: Bug
Components: resourcemanager
Affects Versions: 2.1.0-beta
Reporter: Alejandro Abdelnur
Assignee: Alejandro Abdelnur
Priority: Critical
Fix For: 2.1.1-beta
Attachments: YARN-1144.patch, YARN-1144.patch
Unmanaged AMs do not run in the cluster, their tracking URL should not be
proxy-fied.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (YARN-1144) Unmanaged AMs registering a tracking URI should not be proxy-fied
[
https://issues.apache.org/jira/browse/YARN-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13761256#comment-13761256
]
Hadoop QA commented on YARN-1144:
-
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12602049/YARN-1144.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 2 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}. The javadoc tool did not generate any
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.attempt.TestRMAppAttemptTransitions
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-YARN-Build/1875//testReport/
Console output: https://builds.apache.org/job/PreCommit-YARN-Build/1875//console
This message is automatically generated.
Unmanaged AMs registering a tracking URI should not be proxy-fied
-
Key: YARN-1144
URL: https://issues.apache.org/jira/browse/YARN-1144
Project: Hadoop YARN
Issue Type: Bug
Components: resourcemanager
Affects Versions: 2.1.0-beta
Reporter: Alejandro Abdelnur
Assignee: Alejandro Abdelnur
Priority: Critical
Fix For: 2.1.1-beta
Attachments: YARN-1144.patch, YARN-1144.patch
Unmanaged AMs do not run in the cluster, their tracking URL should not be
proxy-fied.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (YARN-1144) Unmanaged AMs registering a tracking URI should not be proxy-fied
[ https://issues.apache.org/jira/browse/YARN-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alejandro Abdelnur updated YARN-1144: - Attachment: YARN-1144.patch and now ... fixing the testcase. Unmanaged AMs registering a tracking URI should not be proxy-fied - Key: YARN-1144 URL: https://issues.apache.org/jira/browse/YARN-1144 Project: Hadoop YARN Issue Type: Bug Components: resourcemanager Affects Versions: 2.1.0-beta Reporter: Alejandro Abdelnur Assignee: Alejandro Abdelnur Priority: Critical Fix For: 2.1.1-beta Attachments: YARN-1144.patch, YARN-1144.patch, YARN-1144.patch Unmanaged AMs do not run in the cluster, their tracking URL should not be proxy-fied. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (YARN-1144) Unmanaged AMs registering a tracking URI should not be proxy-fied
[
https://issues.apache.org/jira/browse/YARN-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13761263#comment-13761263
]
Hadoop QA commented on YARN-1144:
-
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12602051/YARN-1144.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 2 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}. The javadoc tool did not generate any
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/1876//testReport/
Console output: https://builds.apache.org/job/PreCommit-YARN-Build/1876//console
This message is automatically generated.
Unmanaged AMs registering a tracking URI should not be proxy-fied
-
Key: YARN-1144
URL: https://issues.apache.org/jira/browse/YARN-1144
Project: Hadoop YARN
Issue Type: Bug
Components: resourcemanager
Affects Versions: 2.1.0-beta
Reporter: Alejandro Abdelnur
Assignee: Alejandro Abdelnur
Priority: Critical
Fix For: 2.1.1-beta
Attachments: YARN-1144.patch, YARN-1144.patch, YARN-1144.patch
Unmanaged AMs do not run in the cluster, their tracking URL should not be
proxy-fied.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (YARN-1160) allow admins to force app deployment on a specific host
[ https://issues.apache.org/jira/browse/YARN-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13761511#comment-13761511 ] Alejandro Abdelnur commented on YARN-1160: -- wouldn't make sense, instead having to deal with admin rights, to use a special queue for this and anybody in the queue ACL could manage such services? allow admins to force app deployment on a specific host --- Key: YARN-1160 URL: https://issues.apache.org/jira/browse/YARN-1160 Project: Hadoop YARN Issue Type: Improvement Components: resourcemanager Affects Versions: 3.0.0 Reporter: Steve Loughran Priority: Minor Currently you ask YARN to get slots on a host and it finds a slot on that machine -or, if unavailable or there is no room, on a host nearby as far as the topology is concerned. People with admin rights should have the option to deploy a process on a specific host and have it run there even if there are no free slots -and to fail if the machine is not available. This would let you deploy admin-specific process across a cluster. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (YARN-1165) Move init() of activeServices to ResourceManager#serviceStart()
[ https://issues.apache.org/jira/browse/YARN-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13761516#comment-13761516 ] Bikas Saha commented on YARN-1165: -- HADOOP-9933 would be a pre-requisite to restartable services but we would also need changes in the services themselves to make them restartable in practice. Also, what would be the behavior of other services that inherit from abstract service but dont implement the restartable feature? Do you want to estimate how long it will take to make these services restartable? If thats going to be a long time, then we might have to be tactical and use the approach in 1027-3.patch for now. Its not ideal but practical. The other thing we can see is to see why the tests are failing. If there is a common issue across all tests then we may invest in fixing that. Can you please provide an example of a test failure to explain whats happening. Move init() of activeServices to ResourceManager#serviceStart() --- Key: YARN-1165 URL: https://issues.apache.org/jira/browse/YARN-1165 Project: Hadoop YARN Issue Type: Sub-task Components: resourcemanager Reporter: Karthik Kambatla Assignee: Karthik Kambatla Attachments: test-failures.pdf Background: # YARN-1098 separates out RM services into Always-On and Active services, but doesn't change the behavior in any way. # For YARN-1027, we would want to create, initialize, and start RMActiveServices in the scope of RM#serviceStart(). This requires updating test cases that check for certain behavior post RM#serviceInit() - otherwise, most of these tests NPE. Creating a JIRA different from YARN-1027 to address all these test cases. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (YARN-1098) Separate out RM services into Always On and Active
[ https://issues.apache.org/jira/browse/YARN-1098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13761520#comment-13761520 ] Bikas Saha commented on YARN-1098: -- Patch looks good to me. Karthik, can you please rebase the patch wrt YARN-1107 so that we can commit this. Thanks! Unrelated. Why are the secret manager not services themselves? If they were we wouldnt have to handle them separately in start and stop. Separate out RM services into Always On and Active -- Key: YARN-1098 URL: https://issues.apache.org/jira/browse/YARN-1098 Project: Hadoop YARN Issue Type: Sub-task Components: resourcemanager Affects Versions: 2.1.0-beta Reporter: Karthik Kambatla Assignee: Karthik Kambatla Labels: ha Attachments: yarn-1098-1.patch, yarn-1098-2.patch, yarn-1098-3.patch, yarn-1098-4.patch, yarn-1098-approach.patch, yarn-1098-approach.patch From discussion on YARN-1027, it makes sense to separate out services that are stateful and stateless. The stateless services can run perennially irrespective of whether the RM is in Active/Standby state, while the stateful services need to be started on transitionToActive() and completely shutdown on transitionToStandby(). The external-facing stateless services should respond to the client/AM/NM requests depending on whether the RM is Active/Standby. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (YARN-1027) Implement RMHAServiceProtocol
[
https://issues.apache.org/jira/browse/YARN-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13761524#comment-13761524
]
Bikas Saha commented on YARN-1027:
--
This code is confusing. The state shouldnt be initializing if the service is
stopped. Can we open a jira to add a meaningful state to HAServiceState and
refer to that jira in this code so that we can fix it in that jira too.
{code}
+ public void serviceStop() throws Exception {
+// Stop all services
+transitionToStandby();
+
+// Update haState as RM can no longer be active
+haState = HAServiceState.INITIALIZING;
+super.serviceStop();
{code}
Lets not leave orphan TODOs in the code. Please refer to YARN-1068 or open a
new jira.
{code}
+// TODO: When automatic failover is enabled, check if transition should be
+// allowed for this request
{code}
In transtionToStandby() we are changing state to STANDBY after stopping all
services. This is fine for now. We must keep this in mind later on when we
start having ha-aware alwaysOn services. They need to stop signalling the
ActiveServices before we stop them. Eg. RPC services would need to start
rejecting requests before we stop the activeServices.
createAndStartActiveServices() and related methods should be package visibility
and not protected. Protected would mean that we intend a derived class to see
these methods too.
Is the commented code going to be uncommented or removed? The code is valid and
should work in an active state. So it should probably be uncommented. What
happens if we call this method when the RM is in standby mode? I am wondering
if we may be able to call this during that time and verify that the RM is
indeed not active.
{code}
+ private void checkActiveRMisFunctional() {
+try {
+ rm.getNewAppId();
+// rm.registerNode(node1, 2048);
+ rm.submitApp(1024);
{code}
Locking on the RMHAServiceProtocol is confusing. Some public methods are
synchronized while others are not. Will these lead to race conditions in the
future. How about we make them all public synchronized since they are not
expected to be high performance and so heavy locking is fine. Caveat to this
would be if ZKFC expects getServiceState()/monitorHealth() to work even while
the service is transitioning to active/standby. Again, that probably doesnt
matter if these operations happen in a reasonably short time.
Depending on your conclusion in YARN-1077 we can keep the approach in 1027-3 or
1027-4 wrt RMHAServiceProtocol being always present or not.
Patch is close to being ready for commit! The main thing to verify (even if
manually) is that the ActiveService objects are being GC'd correctly or not.
Implement RMHAServiceProtocol
-
Key: YARN-1027
URL: https://issues.apache.org/jira/browse/YARN-1027
Project: Hadoop YARN
Issue Type: Sub-task
Reporter: Bikas Saha
Assignee: Karthik Kambatla
Attachments: test-yarn-1027.patch, yarn-1027-1.patch,
yarn-1027-2.patch, yarn-1027-3.patch, yarn-1027-4.patch,
yarn-1027-including-yarn-1098-3.patch, yarn-1027-in-rm-poc.patch
Implement existing HAServiceProtocol from Hadoop common. This protocol is the
single point of interaction between the RM and HA clients/services.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (YARN-1059) '\n' or ' ' or '\t' should be ignored for some configuration parameters
[ https://issues.apache.org/jira/browse/YARN-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhijie Shen resolved YARN-1059. --- Resolution: Duplicate The bug will be fixed there '\n' or ' ' or '\t' should be ignored for some configuration parameters --- Key: YARN-1059 URL: https://issues.apache.org/jira/browse/YARN-1059 Project: Hadoop YARN Issue Type: Bug Components: resourcemanager Affects Versions: 2.0.5-alpha Environment: Ubuntu 12.04, hadoop 2.0.5 Reporter: rvller Priority: Minor Labels: newbie Here is the traceback while starting the yarn resourse manager: 2013-08-12 12:53:29,319 FATAL org.apache.hadoop.yarn.server.resourcemanager.ResourceManager: Error starting ResourceManager java.lang.IllegalArgumentException: Does not contain a valid host:port authority: 10.245.1.30:9030 (configuration property 'yarn.resourcemanager.resource-tracker.address') at org.apache.hadoop.net.NetUtils.createSocketAddr(NetUtils.java:193) at org.apache.hadoop.conf.Configuration.getSocketAddr(Configuration.java:1450) at org.apache.hadoop.yarn.server.resourcemanager.ResourceTrackerService.init(ResourceTrackerService.java:105) at org.apache.hadoop.yarn.service.CompositeService.init(CompositeService.java:58) at org.apache.hadoop.yarn.server.resourcemanager.ResourceManager.init(ResourceManager.java:255) at org.apache.hadoop.yarn.server.resourcemanager.ResourceManager.main(ResourceManager.java:710) And here is the yarn-site.xml: configuration property name yarn.resourcemanager.address /name value 10.245.1.30:9010 /value description /description /property property name yarn.resourcemanager.scheduler.address /name value 10.245.1.30:9020 /value description /description /property property name yarn.resourcemanager.resource-tracker.address /name value 10.245.1.30:9030 /value description /description /property property name yarn.resourcemanager.admin.address /name value 10.245.1.30:9040 /value description /description /property property name yarn.resourcemanager.webapp.address /name value 10.245.1.30:9050 /value description /description /property !-- Site specific YARN configuration properties -- /configuration -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (YARN-1170) yarn proto definitions should specify package as 'hadoop.yarn'
Arun C Murthy created YARN-1170: --- Summary: yarn proto definitions should specify package as 'hadoop.yarn' Key: YARN-1170 URL: https://issues.apache.org/jira/browse/YARN-1170 Project: Hadoop YARN Issue Type: Bug Reporter: Arun C Murthy Priority: Blocker yarn proto definitions should specify package as 'hadoop.yarn' similar to protos with 'hadoop.common' 'hadoop.hdfs' in Common HDFS respectively. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (YARN-609) Fix synchronization issues in APIs which take in lists
[ https://issues.apache.org/jira/browse/YARN-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13761554#comment-13761554 ] Zhijie Shen commented on YARN-609: -- The patch looks good to me, but would you please include 4 more *PBImpls which are in server api package and take in lists? 1. NodeHeartbeatResponsePBImpl 2. NodeStatusPBImpl 3. LocalizerHearbeatResponsePBImpl 4. LocalizerStatusPBImpl Since it's not much else, I think it's good to fix together here. Fix synchronization issues in APIs which take in lists -- Key: YARN-609 URL: https://issues.apache.org/jira/browse/YARN-609 Project: Hadoop YARN Issue Type: Bug Reporter: Vinod Kumar Vavilapalli Assignee: Xuan Gong Attachments: YARN-609.1.patch, YARN-609.2.patch, YARN-609.3.patch, YARN-609.4.patch, YARN-609.5.patch, YARN-609.6.patch, YARN-609.7.patch, YARN-609.8.patch Some of the APIs take in lists and the setter-APIs don't always do proper synchronization. We need to fix these. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (YARN-1170) yarn proto definitions should specify package as 'hadoop.yarn'
[ https://issues.apache.org/jira/browse/YARN-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Binglin Chang updated YARN-1170: Attachment: YARN-1170.v1.patch Add namespace to yarn protos also cause some compile error in mapreduce, by the way this patch add hadoop.mapreduce namespace to mapreduce protos. yarn proto definitions should specify package as 'hadoop.yarn' -- Key: YARN-1170 URL: https://issues.apache.org/jira/browse/YARN-1170 Project: Hadoop YARN Issue Type: Bug Reporter: Arun C Murthy Priority: Blocker Attachments: YARN-1170.v1.patch yarn proto definitions should specify package as 'hadoop.yarn' similar to protos with 'hadoop.common' 'hadoop.hdfs' in Common HDFS respectively. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (YARN-353) Add Zookeeper-based store implementation for RMStateStore
[
https://issues.apache.org/jira/browse/YARN-353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13761573#comment-13761573
]
Hitesh Shah commented on YARN-353:
--
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/pom.xml
- shouldn't there be a dependency on zookeeper even in the normal scope?
{code}
+ if (childNodeName.startsWith(DELEGATION_TOKEN_SEQUENCE_NUMBER_PREFIX)) {
+rmState.rmSecretManagerState.dtSequenceNumber =
+Integer.parseInt(childNodeName.split(_)[1]);
+continue;
+ }
{code}
- Could you clarify whether there can be multiple child nodes prefixed with
DELEGATION_TOKEN_SEQUENCE_NUMBER_PREFIX in any possible state variation?
{code}
+ // assert child node name is same as actual applicationId
+ assert appId.equals(appState.context.getApplicationId());
{code}
- why the need for an assert? Should this check throw a runtime exception
instead? (likewise for other assert checks )
{code}
+} catch (Exception e) {
+ // currently throw all exceptions. May need to respond differently for HA
+ // based on whether we have lost the right to write to ZK
+ // TODO: Revisit this post YARN-149
+ throw e;
+}
{code}
- I believe its better to just remove such code and add it in with HA patches.
{code}
+/**
+ * Call exists() to leave a watch on the node denoted by path.
+ * Delete node if exists. To pass the existence information to the
+ * caller, call delete irrespective of whether node exists or not.
+ */
+if (zkClient.exists(path, true) == null) {
+ LOG.error(Trying to delete a path ( + path
+ + ) that doesn't exist.);
+} else {
+ zkClient.delete(path, version);
+}
{code}
- code does not match the comment ( with respect to passing of existence
information )
{code}
+} catch (Exception e) {
+ e.printStackTrace();
+ Assert.fail(ZKRMStateStore Session restore failed);
+}
{code}
- Don't think there is any need to catch the exception. The unit test will
fail if the exception is not caught. If the exception stack trace in the unit
test logs is not useful enough to understand the failure reason, it may be
better to fix the code as needed. ( likewise in the other couple of places in
the unit test where exceptions are being caught and handled with an
assert.fail()
{code}
+Thread.sleep(800);
{code}
- the zk unit test has magic sleeps of 800 ms in some cases, 500 ms in
others. What is the reason for these different numbers? Does the test helper
need augmenting to remove this timing related dependency?
General minor nits:
- 80 chars line limit exceeded in multiple files.
Add Zookeeper-based store implementation for RMStateStore
-
Key: YARN-353
URL: https://issues.apache.org/jira/browse/YARN-353
Project: Hadoop YARN
Issue Type: Sub-task
Components: resourcemanager
Reporter: Hitesh Shah
Assignee: Karthik Kambatla
Attachments: YARN-353.10.patch, YARN-353.11.patch, YARN-353.12.patch,
yarn-353-12-wip.patch, YARN-353.13.patch, YARN-353.14.patch,
YARN-353.15.patch, YARN-353.1.patch, YARN-353.2.patch, YARN-353.3.patch,
YARN-353.4.patch, YARN-353.5.patch, YARN-353.6.patch, YARN-353.7.patch,
YARN-353.8.patch, YARN-353.9.patch
Add store that write RM state data to ZK
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (YARN-609) Fix synchronization issues in APIs which take in lists
[
https://issues.apache.org/jira/browse/YARN-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13761574#comment-13761574
]
Hadoop QA commented on YARN-609:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12601867/YARN-609.8.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}. The javadoc tool did not generate any
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-common.
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-YARN-Build/1877//testReport/
Console output: https://builds.apache.org/job/PreCommit-YARN-Build/1877//console
This message is automatically generated.
Fix synchronization issues in APIs which take in lists
--
Key: YARN-609
URL: https://issues.apache.org/jira/browse/YARN-609
Project: Hadoop YARN
Issue Type: Bug
Reporter: Vinod Kumar Vavilapalli
Assignee: Xuan Gong
Attachments: YARN-609.1.patch, YARN-609.2.patch, YARN-609.3.patch,
YARN-609.4.patch, YARN-609.5.patch, YARN-609.6.patch, YARN-609.7.patch,
YARN-609.8.patch
Some of the APIs take in lists and the setter-APIs don't always do proper
synchronization. We need to fix these.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (YARN-1170) yarn proto definitions should specify package as 'hadoop.yarn'
[
https://issues.apache.org/jira/browse/YARN-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13761591#comment-13761591
]
Hadoop QA commented on YARN-1170:
-
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12602078/YARN-1170.v1.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}. The javadoc tool did not generate any
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-common
hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-hs
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-api
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-common
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager.
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-YARN-Build/1878//testReport/
Console output: https://builds.apache.org/job/PreCommit-YARN-Build/1878//console
This message is automatically generated.
yarn proto definitions should specify package as 'hadoop.yarn'
--
Key: YARN-1170
URL: https://issues.apache.org/jira/browse/YARN-1170
Project: Hadoop YARN
Issue Type: Bug
Reporter: Arun C Murthy
Priority: Blocker
Attachments: YARN-1170.v1.patch
yarn proto definitions should specify package as 'hadoop.yarn' similar to
protos with 'hadoop.common' 'hadoop.hdfs' in Common HDFS respectively.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (YARN-842) Resource Manager Node Manager UI's doesn't work with IE
[
https://issues.apache.org/jira/browse/YARN-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13761600#comment-13761600
]
Nemon Lou commented on YARN-842:
Following Harsh J's advise,a different error occurs :
{code}
user agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/4.0;
SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center
PC 6.0; aff-kingsoft-ciba)
timestamp: Mon, 9 Sep 2013 03:45:49 UTC
message: Object doesn't support this property or method
line: 652
char: 21
code: 0
URI: http://158.1.131.13:8088/static/jt/jquery.jstree.js
{code}
Any suggestions?
Resource Manager Node Manager UI's doesn't work with IE
-
Key: YARN-842
URL: https://issues.apache.org/jira/browse/YARN-842
Project: Hadoop YARN
Issue Type: Bug
Components: nodemanager, resourcemanager
Affects Versions: 2.0.4-alpha
Reporter: Devaraj K
{code:xml}
Webpage error details
User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0;
SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media
Center PC 6.0)
Timestamp: Mon, 17 Jun 2013 12:06:03 UTC
Message: 'JSON' is undefined
Line: 41
Char: 218
Code: 0
URI: http://10.18.40.24:8088/cluster/apps
{code}
RM NM UI's are not working with IE and showing the above error for every
link on the UI.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
