> On Jan. 29, 2015, 3:06 p.m., John Speidel wrote:
> > 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
I assume you are referning to the desciipriton, which I failed to update to
match the code. The code ensures that the security_type is being set to
KERBEROS. Becuase of this, I thought the "kerbreros" in the directive was
redundant as well and it code looks for "regenerate_keytabs".
If transitioning from NONE to KERBEROS, it would not make sense to generate the
keytabs... that would just cause problems.
I think we need to handle the hosts that come up after being down when enabling
Kerberos in a different JIRA.
- Robert
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/30415/#review70265
-----------------------------------------------------------
On Jan. 30, 2015, 9:24 a.m., Robert Levas wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/30415/
> -----------------------------------------------------------
>
> (Updated Jan. 30, 2015, 9:24 a.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}?regenerate_keytabs=true
> {
> "Clusters" : {
> "security_type" : "KERBEROS"
> }
> }
> ```
>
> 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
>
>
