[
https://issues.apache.org/jira/browse/YARN-3895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16166816#comment-16166816
]
Varun Saxena commented on YARN-3895:
------------------------------------
Points to consider including what we discussed on the call.
# Other than read ACLs'. I think we need to have ACLs' restricting modifying an
entity as well i.e. on the write side. Otherwise we may allow some other client
to modify an entity it does not own and change its read ACLs'.
# We can use the application ACLs' passed in AM launch context(available in NM)
and store it in App collector. Will have to pass this info when collector runs
outside NM. If ACLs' are not provided during entity publish, we can
automatically use these app ACLs' as ACLs' for entities. So for MR kind of use
cases, application ACLs' might suffice while for Tez DAGs' in Hive LLAP use
case, entities within an application may have different ACLs' which can be
specified during entity publish.
# If we store ACLs' with each entity, storage size would increase because of
repetition of ACLs'. Should we store some, possibly short ID? Who will generate
a unique ID in the cluster?
# The suggestion above is along the lines of TimelineDomain in ATSv1. Refer to
[link|https://hadoop.apache.org/docs/stable/api/org/apache/hadoop/yarn/api/records/timeline/TimelineDomain.html].
Domain encapsulates set of reader and writer ACLs' and follows the same format
as other YARN ACLs' i.e. if a user belongs to a group and group is within the
same domain to which entity belongs to, we will have access to the entity.
Domain is like a group of user groups and users.
# We can have domain or ACL table in HBase with id as row key. Domains should
be created beforehand i.e. before publishing entities.
# Domain ID can be used as ACL ID but as I said above it will be responsibility
of client to generate a unique ID and then use it consistently while publishing
entities.
# We should consider caching these ACLs' otherwise querying domain table every
time might be suboptimal.
# How to decide flow run/flow level ACLs'? Union of app ACLs' maybe. This needs
some thought. Typically all apps within a flow should have same ACL though.
# A point brought up by Joep. For federation use case, some special handling
required when containers run across clusters? Not sure.
Most importantly, considering GA would be released on Nov 1, we would need to
get this in by 15th October. Do we have enough time? This is more like an
additional feature. Or delay it till 3.1?
> Support ACLs in ATSv2
> ---------------------
>
> Key: YARN-3895
> URL: https://issues.apache.org/jira/browse/YARN-3895
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: timelineserver
> Affects Versions: YARN-2928
> Reporter: Varun Saxena
> Assignee: Varun Saxena
> Labels: YARN-5355
>
> This JIRA is to keep track of authorization support design discussions for
> both readers and collectors.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
