Chris Douglas commented on YARN-3100:

Motivation for the conversion from {{QueueACL}} to the nearly identical, new 
{{YarnAuthorizationProvider.AccessType}}- like the introduction of 
{{PrivilegedEntity}}- is not obvious. Are these pluggable types? Are there 
other, future entities besides queues? Should the authorizer plugin perform the 
mapping from {{QueueACL}}? Just trying to understand the design...

For the {{Default\*}} impl, partial updates for {{refreshQueues}} that become 
visible during the update and after a partial, failed update are hard to reason 
about. While it's a noop for external services, aren't these different 
semantics from the current implementation? Readers are blocked, so there are no 
locks necessary for modifications by {{setPermission}}?

> Make YARN authorization pluggable
> ---------------------------------
>                 Key: YARN-3100
>                 URL: https://issues.apache.org/jira/browse/YARN-3100
>             Project: Hadoop YARN
>          Issue Type: Bug
>            Reporter: Jian He
>            Assignee: Jian He
>         Attachments: YARN-3100.1.patch, YARN-3100.2.patch
> The goal is to have YARN acl model pluggable so as to integrate other 
> authorization tool such as Apache Ranger, Sentry.
> Currently, we have 
> - admin ACL
> - queue ACL
> - application ACL
> - time line domain ACL
> - service ACL
> The proposal is to create a YarnAuthorizationProvider interface. Current 
> implementation will be the default implementation. Ranger or Sentry plug-in 
> can implement  this interface.
> Benefit:
> -  Unify the code base. With the default implementation, we can get rid of 
> each specific ACL manager such as AdminAclManager, ApplicationACLsManager, 
> QueueAclsManager etc.
> - Enable Ranger, Sentry to do authorization for YARN. 

This message was sent by Atlassian JIRA

Reply via email to