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

Varun Vasudev commented on YARN-3443:
-------------------------------------

Thanks for uploading the patch [~sidharta-s]!

Some comments 

# In PrivilegedOperationExecutor.java
{noformat}
catch (ExitCodeException e) {
  if (LOG.isWarnEnabled()) {
     LOG.warn("Shell execution returned exit code: " + exec.getExitCode());
     LOG.warn("Privileged Execution Operation Output:");
     LOG.warn(exec.getOutput());
  }
}
{noformat}
Can you merge the warnings into one warn message and add the exception to the 
log message? This is so that alerts based on the number of errors/warnings 
reflect the actual number.
# In CGroupHandlerImpl.java
{noformat}
if (enableCGroupMount) {
    //nothing to do here - we support 'deferred' mounting of specific
    //controllers - we'll populate the path for a given controller when an
    //explicit mountCGroupController request is issued.
} else {
    //cluster admins are expected to have mounted controllers in specific
    //locations - we'll attempt to figure out mount points
    initializeControllerPathsFromMtab();
}
{noformat}
Can we remove the empty if block?
# In CGroupHandlerImpl.java
{noformat}
LOG.error("Mount point Based on mtab file : " + MTAB_FILE);
LOG.error("Controller mount point not writable for: " + name);
{noformat}
Merge the log messages
# In CGroupHandlerImpl.java
{noformat}
LOG.warn("Failed to initialize controller paths!");
LOG.warn(e);
{noformat}
Merge the log messages
# In CGroupHandlerImpl.java
In initializeControllerPathsFromMtab, when the error and warnings are logged, 
should we throw an exception, since the functionality being requested will not 
work?
# In CGroupHandlerImpl.java
In mountCGroupController
{noformat}
if (!enableCGroupMount) {
    if (LOG.isWarnEnabled()) {
      LOG.warn("CGroup mounting is disabled - ignoring mount request for: " +
            controller.getName());
      return;
    }
}
{noformat}
Should this be an error with an exception being thrown since the functionality 
being requested won't be possible?
# In CGroupHandlerImpl.java
{noformat}
@param file object referring to the cgroup to be deleted mislabelled
{noformat}
The param name is mislabeled. It should be cgf instead of file
# In ResourceHandler.java
{noformat}
   * @param containerId if of the container being reacquired.
   * @return
   * @throws ResourceHandlerException
{noformat}
return is missing description
# In ResourceHandler.java
{noformat}
List<PrivilegedOperation> postComplete(ContainerId containerId) throws
      ResourceHandlerException;

;
{noformat}
There's an extra semi-colon.
# In TestPrivilegedOperationExecutor.java
{noformat}
expectedPath = customExecutorPath;
containerExePath = PrivilegedOperationExecutor
        .getContainerExecutorExecutablePath(confWithExecutorPath);
Assert.assertEquals(expectedPath, customExecutorPath);
{noformat}
containerExePath is not used. The assert will always succeed since you set them 
to be equal before calling the function. Did you mean to compare 
containerExePath and expectedPath?
# In TestPrivilegedOperationExecutor.java
{noformat}
prefixLength + 0
{noformat}
Remove the 0?
# In TestPrivilegedOperationExecutor.java
{noformat}
try {
      PrivilegedOperationExecutor.squashCGroupOperations(ops);
} catch (PrivilegedOperationException e) {
      if (LOG.isInfoEnabled()) {
        LOG.info("Caught expected exception : " + e);
      }
      caughtPrivilegedOperationException = true;
}

Assert.assertTrue("Expected squash operation to fail!",
        caughtPrivilegedOperationException);
{noformat}
Instead of using the boolean to check if the exception was thrown, you can use 
Assert.fail in the try block. This pattern occurs multiple times.
# I think the formatting is a bit off in a couple of files. Can you apply the 
formatter and check?

> Create a 'ResourceHandler' subsystem to ease addition of support for new 
> resource types on the NM
> -------------------------------------------------------------------------------------------------
>
>                 Key: YARN-3443
>                 URL: https://issues.apache.org/jira/browse/YARN-3443
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: nodemanager
>            Reporter: Sidharta Seethana
>            Assignee: Sidharta Seethana
>         Attachments: YARN-3443.001.patch, YARN-3443.002.patch
>
>
> The current cgroups implementation is closely tied to supporting CPU as a 
> resource . We need to separate out CGroups support as well a provide a simple 
> ResourceHandler subsystem that will enable us to add support for new resource 
> types on the NM - e.g Network, Disk etc. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to