ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nate Cole" <nc...@hortonworks.com>
Subject Re: Review Request 39337: Ambari 1.7 to 2.1.x upgrade with existing Kerberos, keytab files fail to be distributed to some hosts
Date Thu, 15 Oct 2015 13:23:05 GMT

-----------------------------------------------------------
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
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message