[
https://issues.apache.org/jira/browse/YARN-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Yang updated YARN-7605:
----------------------------
Attachment: YARN-7605.014.patch
[~jianhe] . Thanks for the review:
{quote}
Previous comment: Here it still assumes if result != 0 , it is
ApplicationNotFoundException. I think this is inappropriate, in fact in the
implementation, it'll not return result!=0, so this condition may be just
removed.
{quote}
I added a check to return EXIT_NOT_FOUND in actionDestroy, if the file is not
found in HDFS, it will return the proper application not found information.
{quote}
It is inappropriate to assume all exceptions are caused by "Permission denied" ?
{quote}
I removed the capture of exception, and allow the exception to be handled at
upper layer.
{quote}
In getStatus is is changed to load from hdfs every time, won't this hit hdfs
too much ?
{quote}
I refactor the code to load only if RM doesn't find the app.
{quote}
why is below code in getStatus removed ?
{quote}
Redundant fetch of information. If it is running, remaining time is in the
copy retrieved from AM.
{quote}
I meant why this patch added the InterruptedException to this submitApp
interface ? it wasn't throwing InterruptedException before
{quote}
I removed InterruptedException, sorry about this.
{quote}
Looks like methods are not exceeding 80 column limit and looks truncated to
separate lines unnecessarily. what were the checkstyles about ?
{quote}
Both lines are 81 characters.
{quote}
there's always this line printed when trying the CLI, any way to get rid of
this ?
{quote}
Not sure how to get rid of this.
{quote}
For flexing it doesn't print flexed from/to numbers, I think it is useful to
print 'component name' and from/to numbers
{quote}
Fixed.
{quote}
both stop and destroy will print the same logging as below, I think we can
differentiate them
“Successfully stopped service”
{quote}
Fixed
{quote}
"yarn app -save" doesn't have logging to indicate whether it is succesful or not
{quote}
Fixed.
> Implement doAs for Api Service REST API
> ---------------------------------------
>
> Key: YARN-7605
> URL: https://issues.apache.org/jira/browse/YARN-7605
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Eric Yang
> Assignee: Eric Yang
> Fix For: yarn-native-services
>
> Attachments: YARN-7605.001.patch, YARN-7605.004.patch,
> YARN-7605.005.patch, YARN-7605.006.patch, YARN-7605.007.patch,
> YARN-7605.008.patch, YARN-7605.009.patch, YARN-7605.010.patch,
> YARN-7605.011.patch, YARN-7605.012.patch, YARN-7605.013.patch,
> YARN-7605.014.patch
>
>
> In YARN-7540, all client entry points for API service is centralized to use
> REST API instead of having direct file system and resource manager rpc calls.
> This change helped to centralize yarn metadata to be owned by yarn user
> instead of crawling through every user's home directory to find metadata.
> The next step is to make sure "doAs" calls work properly for API Service.
> The metadata is stored by YARN user, but the actual workload still need to be
> performed as end users, hence API service must authenticate end user kerberos
> credential, and perform doAs call when requesting containers via
> ServiceClient.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
