[jira] [Created] (YARN-11589) Router Policy support user as default queue
liu bin created YARN-11589: -- Summary: Router Policy support user as default queue Key: YARN-11589 URL: https://issues.apache.org/jira/browse/YARN-11589 Project: Hadoop YARN Issue Type: Improvement Components: federation Reporter: liu bin In my cluster, RM is configured to map users to queues, and users do not specify queues when submitting jobs. When using router, we do not want to change user behavior, so I think we can add config to use user as default queue when getting router policy by queue. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org
[jira] [Created] (YARN-11574) Make yarn router webservice forward auth configurable
liu bin created YARN-11574: -- Summary: Make yarn router webservice forward auth configurable Key: YARN-11574 URL: https://issues.apache.org/jira/browse/YARN-11574 Project: Hadoop YARN Issue Type: Improvement Components: router, yarn Reporter: liu bin Now we can't request yarn router apps page without authentication, because router webservice will try to get callerUGI from HttpServletRequest. I think we can check the config `hadoop.http.authentication.type` to determine whether the user should be authenticated. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org
[jira] [Created] (YARN-11304) Upgrade nodemanager's exception log level
liu bin created YARN-11304: -- Summary: Upgrade nodemanager's exception log level Key: YARN-11304 URL: https://issues.apache.org/jira/browse/YARN-11304 Project: Hadoop YARN Issue Type: Improvement Reporter: liu bin Upgrade nodemanager's localizer failed log level from info to warn. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org
[jira] [Created] (YARN-11213) DecommissioningNodesWatcher#logDecommissioningNodesStatus calculate app elapsed time error
liu bin created YARN-11213:
--
Summary: DecommissioningNodesWatcher#logDecommissioningNodesStatus
calculate app elapsed time error
Key: YARN-11213
URL: https://issues.apache.org/jira/browse/YARN-11213
Project: Hadoop YARN
Issue Type: Bug
Reporter: liu bin
There is a calculation in
DecommissioningNodesWatcher#logDecommissioningNodesStatus to calculate app
elapsed time:
{code:java}
(mclock.getTime() - rmApp.getStartTime()) / 1000{code}
But mclock.getTime() is get from System.nanoTime() /
NANOSECONDS_PER_MILLISECOND, rmApp.getStartTime() is get from
System.currentTimeMillis(), they cannot be compared.
This calculation should be:
{code:java}
(System.currentTimeMillis() - rmApp.getStartTime()) / 1000{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org
[jira] [Created] (YARN-11207) Add configuration to disable queue's user resource limit
liu bin created YARN-11207: -- Summary: Add configuration to disable queue's user resource limit Key: YARN-11207 URL: https://issues.apache.org/jira/browse/YARN-11207 Project: Hadoop YARN Issue Type: Improvement Components: capacityscheduler Reporter: liu bin In my cluster, a queue is only used by one user, so there is no need to limit user resource. I think we can add configuration to disable the user resource limit. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org
[jira] [Created] (YARN-11206) Consider queue's max capacity as max am resource limit for labeled partition
liu bin created YARN-11206: -- Summary: Consider queue's max capacity as max am resource limit for labeled partition Key: YARN-11206 URL: https://issues.apache.org/jira/browse/YARN-11206 Project: Hadoop YARN Issue Type: Improvement Components: capacityscheduler Reporter: liu bin When calculate am resource limit per partition in capacityscheduler, for non-labeled partition, get the max value from resources currently available to the queue and the absolute resources guaranteed for the partition in the queue. But for labeled partition, consider only the absolute resources guaranteed. It may be confused when we configure the queue. I think we can consider queue's max capacity as max am resource limit for labeled partition. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org
[jira] [Created] (YARN-11205) Do not reset max applications for a queue based on absolute capacity
liu bin created YARN-11205: -- Summary: Do not reset max applications for a queue based on absolute capacity Key: YARN-11205 URL: https://issues.apache.org/jira/browse/YARN-11205 Project: Hadoop YARN Issue Type: Bug Components: capacityscheduler Reporter: liu bin when we use absolute resource configuration in capacityscheduler, the max applications will be reset based on queue‘s AbsoluteCapacity. When the cluster is just started and nodemanager has not been registered, max applications will be set to 0, applications cannot be submitted. RM log: LeafQueue:root.hadoop, maxApplications=0, maxApplicationsPerUser=0, Abs Cap:NaN I think it's meaningless to reset max applications, so we can just delete these codes. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: yarn-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-dev-h...@hadoop.apache.org
