hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Douglas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-3100) Make YARN authorization pluggable
Date Thu, 05 Feb 2015 22:25:37 GMT

    [ 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)

Mime
View raw message