[AMBARI-5729] Decommission issues in secure cluster.

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 1.6.0
• Assignee: Andrew Onischuk
• Reporter: Andrew Onischuk
• Created: 12/May/14 10:45
• Updated: 12/May/14 10:55
• Resolved: 12/May/14 10:54

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.

Issue Links

• links to: ReviewBoard