-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/39337/#review102778
-----------------------------------------------------------

Ship it!


Ship It!

- Nate Cole


On Oct. 15, 2015, 7:37 a.m., Robert Levas wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39337/
> -----------------------------------------------------------
> 
> (Updated Oct. 15, 2015, 7:37 a.m.)
> 
> 
> Review request for Ambari, Jonathan Hurley, Nate Cole, Robert Nettleton, and 
> Sumit Mohanty.
> 
> 
> Bugs: AMBARI-13425
>     https://issues.apache.org/jira/browse/AMBARI-13425
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> When upgrading from Ambari 1.7 to 2.1.x, where the source cluster has been 
> Kerberized, keytab files fail to distribute to some hosts.  
> 
> # Steps to reproduce
> - Create cluster with Ambari 1.7.0 (multiple nodes, required)
> - Enable Kerberos (manually)
> - Upgrade to Ambari 2.1.2
> - Enable Kerberos (automated)
> - Not all hosts will receive keytab files
> 
> # Cause
> This is due to the way Ambari keeps track of which components (on each host) 
> are properly Kerberized.  So if Kerberos was enabled before the upgrade to 
> 2.x, at some point the agents will report back to Ambari that its components 
> are secured with Kerberos.  Ambari will then use this data to determine which 
> hosts need to be processed when enabling Kerberos. If some of the hosts have 
> reported back before the determination of which hosts need to be process, 
> those hosts will most-likely be skipped and thus, the new keytab files will 
> not be distributed to them.
> 
> # Solution
> The solution is to remove outdated code previously used to determine how to 
> handle scenarios where new services are added to a Kerberized cluster.  This 
> code compared the existing services' security state with some desired 
> security state.  If they matched, then no work needed to be done.  The state 
> in particular is `SECURED_KERBEROS` and can be seen in the `security_state` 
> column of the `hostcomponentstate` table.  
> 
> The code in question is outdated since new services being added to a 
> Kerberized cluster no longer  requires the invocation of the 
> `KerberosHelper.toggleKerberos` method.  The current implementing invokes 
> more granular code to  configure the relevant service(s) and generate the 
> Kerberos identities in a more granular fashion during state changes rather 
> then after the fact.
> 
> 
> Diffs
> -----
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java
>  dbb59bd 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementControllerImplTest.java
>  dd80f46 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/KerberosHelperTest.java
>  97e1b7e 
> 
> Diff: https://reviews.apache.org/r/39337/diff/
> 
> 
> Testing
> -------
> 
> Manually tested
> 
> # Local test results:  
> Updated unit tests passed, existing non-related unit tests failed (they fail 
> w/o this patch as well)
> 
> # Jenkins test results: PENDING
> 
> 
> Thanks,
> 
> Robert Levas
> 
>

Reply via email to