[
https://issues.apache.org/jira/browse/YARN-6734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16102691#comment-16102691
]
Vrushali C commented on YARN-6734:
----------------------------------
bq. I didn't see any advantage sending UGI into backend implementation. Is it
required?
I too don't know exactly how we would use it. I am wondering if the
authentication related info that we have to perhaps store with each record
would need this user / proxy user / groups of this user type of info that comes
from UGI.
And since this is an API change for the writer, I was wondering do we want to
make it now itself? If we change it later, would it be an issue? No one calls
the writer other than the collector right? I mean, the AMs or other frameworks
wont write to writer directly.
What do you both think
cc [~varun_saxena]
> Ensure sub-application user is extracted & sent to timeline service
> -------------------------------------------------------------------
>
> Key: YARN-6734
> URL: https://issues.apache.org/jira/browse/YARN-6734
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: timelineserver
> Reporter: Vrushali C
> Assignee: Rohith Sharma K S
> Attachments: YARN-6734-YARN-5355.001.patch,
> YARN-6734-YARN-5355.002.patch, YARN-6734-YARN-5355.003.patch
>
>
> After a discussion with Tez folks, we have been thinking over introducing a
> table to store sub-application information. YARN-6733
> For example, if a Tez session runs for a certain period as User X and runs a
> few AMs. These AMs accept DAGs from other users. Tez will execute these dags
> with a doAs user. ATSv2 should store this information in a new table perhaps
> called as "sub_application" table.
> YARN-6733 tracks the code changes needed for table schema creation.
> This jira tracks writing to that table, updating the user name fields to
> include sub-application user etc. This would mean adding a field to Flow
> Context which can store an additional user
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
