ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Onischuk (JIRA)" <>
Subject [jira] [Resolved] (AMBARI-5729) Decommission issues in secure cluster.
Date Mon, 12 May 2014 10:55:14 GMT


Andrew Onischuk resolved AMBARI-5729.

    Resolution: Fixed

Committed to trunk

> Decommission issues in secure cluster.
> --------------------------------------
>                 Key: AMBARI-5729
>                 URL:
>             Project: Ambari
>          Issue Type: Bug
>            Reporter: Andrew Onischuk
>            Assignee: Andrew Onischuk
>             Fix For: 1.6.0
> Yarn package 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
>   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 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

View raw message