hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jian He (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-7605) Implement doAs for Api Service REST API
Date Mon, 08 Jan 2018 23:17:01 GMT

    [ https://issues.apache.org/jira/browse/YARN-7605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16317313#comment-16317313
] 

Jian He commented on YARN-7605:
-------------------------------

- 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.
{code}
    if (result == 0) {
      ServiceStatus serviceStatus = new ServiceStatus();
      serviceStatus.setDiagnostics("Successfully stopped service " +
          appName);
      return formatResponse(Status.OK, serviceStatus);
    } else {
      throw new ApplicationNotFoundException("Service " + appName +
          " is not found in YARN.");
    }
{code}
- previous comment: It is inappropriate to assume all exceptions are caused by "Permission
denied" ? this will confuse the users. And why not just use LOG.warn("...", e), but use a
seaprate log statement for the exception ?
{code}
    try {
      proxy.flexComponents(requestBuilder.build());
    } catch (YarnException | IOException e) {
      LOG.warn("Exception caught during flex operation.");
      LOG.warn(ExceptionUtils.getFullStackTrace(e));
      throw new YarnException("Permission denied to perform flex operation.");
    }
{code}
- In getStatus is is changed to load from hdfs every time, won't this hit hdfs too much ?

{code}
    Service appSpec = ServiceApiUtil.loadService(fs, serviceName);
{code} 

- why is below code in getStatus removed ?
{code}
    ApplicationTimeout lifetime =
        appReport.getApplicationTimeouts().get(ApplicationTimeoutType.LIFETIME);
    if (lifetime != null) {
      appSpec.setLifetime(lifetime.getRemainingTime());
    }
{code}
- bq. In ServiceClient, several methods shouldn't throw InterruptedException because AppAdminClient
definition doesn't throw InterruptedException. This is the reason that InterruptedException
were converted to YarnException
I meant why this patch added the InterruptedException to this submitApp interface ? it wasn't
throwing InterruptedException before
{code}
  private ApplicationId submitApp(Service app)
      throws IOException, YarnException, InterruptedException {
{code}
- bq. Formatting for createAMProxy, actionSave were to remove some check style issues that
exist in ServiceClient.
Looks like methods are not exceeding 80 column limit and looks truncated to separate lines
unnecessarily. what were the checkstyles about ?
- there's always this line printed when trying the CLI, any way to get rid of this ?
{code}18/01/08 14:31:35 INFO util.log: Logging initialized @1287ms
{code}
- For flexing it doesn't print flexed from/to numbers, I think it is useful to print 'component
name' and from/to numbers 
{code}
18/01/08 14:33:44 INFO client.ApiServiceClient: Service jian2 is successfully flexed.
{code}

- both stop and destroy will print the same logging as below, I think we can differentiate
them
“Successfully stopped service”
-  "yarn app -save" doesn't have logging to indicate whether it is succesful or not

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


Mime
View raw message