[ https://issues.apache.org/jira/browse/YARN-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16317647#comment-16317647 ]
Jian He commented on YARN-7605: ------------------------------- bq. 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. still the logic that "result != 0" means application is not found is fragile. The next time user added a new exit code, this error message is broken. And currently it is inconsistent between CLI and rest API. CLI is ignoring the error code whereas rest API is throwing exception. It's better to make them consistent. And the Exception that ApplicationNotFound is confusing, ApplicationNotFound usually means not found in RM, but here it is the app folder not existing in hdfs. I think we can return the fact that the app doesn't exist hdfs to be explicit, like the CLI does, instead of throwing exception. bq. I refactor the code to load only if RM doesn't find the app. IIUC, the code is load if app is not running. This can be that app is pending or finished, it may still hit hdfs a lot. For getStatus kinda API, the consumer is always calling it in a loop. This will get very bad if hdfs is down or during failover, the api call will be spinning and quickly overload RM. IMO, we may need a better solution for serving persistent app status. The current approach may create a bottleneck accidentally. bq. Redundant fetch of information. If it is running, remaining time is in the copy retrieved from AM. How is it retrieving it from AM ? Only RM knows the app's remaining time bq. Patch failed due to revert of YARN-7540. Please commit YARN-7540 so this patch can be applied. Thank you. Once this patch review is done, we can combine both patches and run jenkins and commit together. > 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