[
https://issues.apache.org/jira/browse/AMBARI-5729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Onischuk updated AMBARI-5729:
------------------------------------
Description:
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.
was:
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 (Introduced by
<del>[BUG-14307</del>](https://hortonworks.jira.com/browse/BUG-14307) commit).
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.
> 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)
