[ 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