[ 
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: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org

Reply via email to