hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gordon Wang (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (YARN-1941) Yarn scheduler ACL improvement
Date Tue, 15 Apr 2014 08:55:14 GMT

     [ https://issues.apache.org/jira/browse/YARN-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Gordon Wang updated YARN-1941:
------------------------------

    Description: 
Defect:
1. Currently, in Yarn Capacity Scheduler and Yarn Fair Scheduler, the queue ACL is always
checked when submitting a app to scheduler, regardless of the property "yarn.acl.enable".
But for killing an app, the ACL is checked when yarn.acl.enable is set.
The behaviour is not consistent.

2. default ACL for root queue is EVERYBODY_ACL( * ), while default ACL for other queues is
NODODY_ACL( ). From users' view, this is error prone and not easy to understand the ACL policy
of Yarn scheduler. root queue should not be so special compared with other parent queues.
For example, if I want to set capacity scheduler ACL, the ACL of root has to be set explicitly.
Otherwise, everyone can submit APP to yarn scheduler. Because root queue ACL is EVERYBODY_ACL.
This is hard for user to administrate yarn scheduler.

So, I propose to improve the ACL of yarn scheduler in the following aspects.
1. only enable scheduler queue ACL when yarn.acl.enable is set to true.
2. set the default ACL of root queue as NOBODY_ACL( ). Make all the parent queues' ACL consistent.
 

  was:
Defect:
1. Currently, in Yarn Capacity Scheduler and Yarn Fair Scheduler, the queue ACL is always
checked when submitting a app to scheduler, regardless of the property "yarn.acl.enable".
But for killing an app, the ACL is checked when yarn.acl.enable is set.
The behaviour is not consistent.

2. default ACL for root queue is EVERYBODY_ACL(*), while default ACL for other queues is NODODY_ACL(
). From users' view, this is error prone and not easy to understand the ACL policy of Yarn
scheduler. root queue should not be so special compared with other parent queues.
For example, if I want to set capacity scheduler ACL, the ACL of root has to be set explicitly.
Otherwise, everyone can submit APP to yarn scheduler. Because root queue ACL is EVERYBODY_ACL.
This is hard for user to administrate yarn scheduler.

So, I propose to improve the ACL of yarn scheduler in the following aspects.
1. only enable scheduler queue ACL when yarn.acl.enable is set to true.
2. set the default ACL of root queue as NOBODY_ACL( ). Make all the parent queues' ACL consistent.
 


> Yarn scheduler ACL improvement
> ------------------------------
>
>                 Key: YARN-1941
>                 URL: https://issues.apache.org/jira/browse/YARN-1941
>             Project: Hadoop YARN
>          Issue Type: Improvement
>          Components: scheduler
>    Affects Versions: 2.3.0
>            Reporter: Gordon Wang
>              Labels: scheduler
>
> Defect:
> 1. Currently, in Yarn Capacity Scheduler and Yarn Fair Scheduler, the queue ACL is always
checked when submitting a app to scheduler, regardless of the property "yarn.acl.enable".
> But for killing an app, the ACL is checked when yarn.acl.enable is set.
> The behaviour is not consistent.
> 2. default ACL for root queue is EVERYBODY_ACL( * ), while default ACL for other queues
is NODODY_ACL( ). From users' view, this is error prone and not easy to understand the ACL
policy of Yarn scheduler. root queue should not be so special compared with other parent queues.
> For example, if I want to set capacity scheduler ACL, the ACL of root has to be set explicitly.
Otherwise, everyone can submit APP to yarn scheduler. Because root queue ACL is EVERYBODY_ACL.
> This is hard for user to administrate yarn scheduler.
> So, I propose to improve the ACL of yarn scheduler in the following aspects.
> 1. only enable scheduler queue ACL when yarn.acl.enable is set to true.
> 2. set the default ACL of root queue as NOBODY_ACL( ). Make all the parent queues' ACL
consistent.
>  



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message