[ 
https://issues.apache.org/jira/browse/YARN-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14308239#comment-14308239
 ] 

Jian He commented on YARN-3100:
-------------------------------

Chris, appreciate your feedbacks !
bq. These (1) will be observable by readers of Q who share the instance.
bq. I'm curious if (1) and (2) are an artifact of the new plugin architecture 
or if this is also happens in the existing code
IIUC, in case refreshQueue is successful, readers won't be able to observe the 
new Q' ACL. because while constructing new Q', it's holding the scheduler lock, 
and the reader(i.e. the caller of checkPermission) has to get the same 
scheduler lock to check permission. So I think readers won't be able to observe 
the new ACL until Q refresh is completed. But I agree with you that if 
construction of Q' fails, we possibly get a mix of  Q' and Q ACLs, which 
happens in the existing code. This could be a problem to other parts of the 
refreshQueue too, e.g. update queue capacity. 
bq. I suppose it could track the sequence of calls that install ACLs and only 
publish new ACLs when it's received updates for everything,
Yes, a simple way is that the plug-in can check if the acl already exists and 
only add the new ones. As you said, this is not clean. I think maybe we can 
print warning if admin uses external component for ACL management but still 
call the refreshQueue API to update the ACL. 
 bq. but that could still yield (2) if the refresh adds new queues before the 
refresh fails.
Yes, it will still yield 2) if refresh fails. 

> 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
(v6.3.4#6332)

Reply via email to