-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/30415/#review70265
-----------------------------------------------------------
The api should include a body that contains the security_type property.
{
"Clusters" : {
"security_type" : "kerberos"
}
}
The directive only makes sense in this context.
Basically the directive is saying that even if this property is already set to
"kerberos" that you still want to generate the keytabs.
With the context of the body, you can potentially remove "kerberos" from the
directive name.
Would a user ever want to transition from security_type = "none" ->
security_type = "kerberos" and not want to generate keytabs by specifying this
directive with a false value? If so, then we should also handle the user
specifying this directive with a false value.
Based on the call we had yesterday, it seems that we will also need the ability
to generate keytabs for all hosts that we were originally unable to distribute
to when we first kerberized the cluster or added hosts ...
We should keep this in mind when naming the directive.
Something like:
generate_keytabs = true : regenerate/distribute all keytabs
generate_missing_keytabs = true : only for hosts that need it
- John Speidel
On Jan. 29, 2015, 2:55 p.m., Robert Levas wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30415/
> -----------------------------------------------------------
>
> (Updated Jan. 29, 2015, 2:55 p.m.)
>
>
> Review request for Ambari, John Speidel, Nate Cole, Robert Nettleton, and Tom
> Beerbower.
>
>
> Bugs: AMBARI-9385
> https://issues.apache.org/jira/browse/AMBARI-9385
>
>
> Repository: ambari
>
>
> Description
> -------
>
> Create API entry point to initiate Kerberos keytab regeneration for the
> cluster:
> ```
> PUT /api/v1/clusters/{clustername}?kerberos_regenerate_keytabs=true
> ```
>
> The entry point should invoke code to determine which principals need to be
> updated and then generate the following stages:
> # Update Principal Passwords
> # Generate Keytabs
> # Distribute Keytab
>
>
> Diffs
> -----
>
>
> ambari-server/src/main/java/org/apache/ambari/server/api/resources/ClusterResourceDefinition.java
> 9b744d0
>
> ambari-server/src/main/java/org/apache/ambari/server/controller/AmbariManagementControllerImpl.java
> e867f99
>
> ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelper.java
> 6bb9bf1
>
> ambari-server/src/test/java/org/apache/ambari/server/controller/AmbariManagementControllerImplTest.java
> 1a66cd9
>
> ambari-server/src/test/java/org/apache/ambari/server/controller/KerberosHelperTest.java
> e976d81
>
> Diff: https://reviews.apache.org/r/30415/diff/
>
>
> Testing
> -------
>
> Manually tested in cluster again MIT KDC (Active Directory pending)
> Updated unit tests
>
> # Jenkins test results
> Running org.apache.ambari.server.controller.AmbariManagementControllerImplTest
> Tests run: 30, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 6.099 sec
>
> Running org.apache.ambari.server.controller.KerberosHelperTest
> Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.626 sec
>
> Ambari-server test results
> Tests run: 2631, Failures: 0, Errors: 0, Skipped: 15
>
> **Note: Python tests are broken on the trunk, unrelated to this change**
>
>
> Thanks,
>
> Robert Levas
>
>
