[
https://issues.apache.org/jira/browse/YARN-3100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14308126#comment-14308126
]
Chris Douglas commented on YARN-3100:
-------------------------------------
bq. The reinitializeQueues looks to be transactional, it instantiates all new
sub queues first and then update the root queue and child queues accordingly.
And the checkAccess chain will compete the same scheduler lock with the
refreshQueue.
If there's a queue with root _Q_, say we're constructing _Q'_. In the current
patch, the {{YarnAuthorizationProvider}} singleton instance will get calls to
{{setPermission()}} during construction of _Q'_. These (1) will be observable
by readers of _Q_ who share the instance. I agree that if construction of _Q'_
fails then it won't get installed, but (2) _Q_ will run with a mix of _Q'_ and
_Q_ ACLs because each call to {{setPermission()}} overwrites what was installed
for _Q_.
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. Not for external implementations,
but for the {{Default\*}} one.
bq. Alternatively, the plug-in can choose to add new acl via the setPermission
when refreshQueue is invoked, but not to replace existing acl. Also, whether to
add new or update or no, this is something that plug-in itself can decide or
make it configurable by user.
Maybe I'm being dense, but I don't see how a plugin could implement those
semantics cleanly. {{YarnAuthorizationProvider}} forces the instance to be a
singleton, and it gets some sequence of calls to {{setPermission()}}. Since
queues can't be deleted in the CS, I suppose it could track the sequence of
calls that install ACLs and only publish new ACLs when it's received updates
for everything, but that could still yield (2) if the refresh adds new queues
before the 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)
