[jira] [Commented] (AMBARI-5729) Decommission issues in secure cluster.

["Andrew Onischuk (JIRA)" <ji...@apache.org>]

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

Andrew Onischuk commented on AMBARI-5729:
-----------------------------------------

Committed to branch-1.6.0

> Decommission issues in secure cluster.
> --------------------------------------
>
>                 Key: AMBARI-5729
>                 URL: https://issues.apache.org/jira/browse/AMBARI-5729
>             Project: Ambari
>          Issue Type: Bug
>            Reporter: Andrew Onischuk
>            Assignee: Andrew Onischuk
>             Fix For: 1.6.0
>
>
> Yarn package params.py file references to `nodemanager_principal_name` and
> `nodemanager_keytab` properties. There are 3 issues over here:
>   1. Ideally, Ambari agent should not access and so not even refer to any service principal name.
>   2. If required, Ambari agent should use yarn-site properties to fetch service principal name and keytab path instead of using global properties.
>   3. In the resourcemanager.py decomission action, Yarn user kinit's using nodemanager principal. Decommission action is always executed on resourcemanager host and so we should atleast use resource manager principal (as it is guaranteed to be on that host). **As of now in a secure cluster if NodeManager is not present on ResourceManager host then NodeManager decomissioning won't work (due to unavailability of NodeManager keytab)**
> Also ambari-agent **does not kinit before executing DataNode decommission
> command**. If an API request for decommissioning is made after hdfs user
> kerberos ticket has expired then the request will fail due to kerberos
> exception.



--
This message was sent by Atlassian JIRA
(v6.2#6252)