[
https://issues.apache.org/jira/browse/YARN-6727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16074516#comment-16074516
]
Sunil G commented on YARN-6727:
-------------------------------
I guess I ll put my thoughts more clearer for better clarity in terms of
understanding.
# Invoking {{YarnScheduler#checkAccess}} is safer for CS as we lock with a
readLock only in YarnAuthorizationProvider where as FS still has some locks in
scheduler. So we can try limiting the checkAccess as possible.
# Whichever user is passed with checkAccess at one point of time (from cli/api
side or app submission time etc) could be cached. I prefer this to be stored
outside scheduler.
# So any further {{getQueueUserAcls}} could look into cache for first time. And
given a cache miss, we can do {{YarnScheduler#checkAccess}} and update cache.
# Cache could be invalidated in cases here a config refresh happened for
queues/acls or in similar conditions.
Given if changes are minimal, we can do in one ticket. But if its more, I am in
favor of splitting to 2 jiras for api and scheduler.
> Improve getQueueUserAcls API to query for specific queue and user
> ------------------------------------------------------------------
>
> Key: YARN-6727
> URL: https://issues.apache.org/jira/browse/YARN-6727
> Project: Hadoop YARN
> Issue Type: Improvement
> Reporter: Bibin A Chundatt
> Assignee: Bibin A Chundatt
> Attachments: YARN-6727.WIP.patch
>
>
> Currently {{ApplicationClientProtocol#getQueueUserAcls}} return data for all
> the queues available in scheduler for user.
> User wants to know whether he has rights of a particular queue only. For
> systems with 5K queues returning all queues list is not efficient.
> Suggested change: support additional parameters *userName and queueName* as
> optional. Admin user should be able to query other users ACL for a particular
> queueName.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
