I don't remember the exact details as it was a while ago but the comments in 
https://hortonworks.jira.com/browse/BUG-48963 should have it.

Felad?: Robert Levas
Elk?ldve: j?lius 10., vas?rnap 15:35
T?rgy: Re: Review Request 49826: AUTH_TO_LOCAL rules are not updated when 
adding services to a Blueprint-installed cluster
C?mzett: Jonathan Hurley, Sebastian Toader, Alejandro Fernandez, Nate Cole
M?solat: Robert Levas, Sumit Mohanty, Ambari

This is an automatically generated e-mail. To reply, visit: 

On July 10th, 2016, 3:12 a.m. EDT, Sebastian Toader wrote:

 (Diff revision 1) public void setAuthToLocalRules(KerberosDescriptor 
kerberosDescriptor, Cluster cluster, String realm,871 if 
(cluster.isBluePrintDeployed()) {900 if (cluster.isBluePrintDeployed()) {

The {{cluster.isBluePrintDeployed()}} tells if this cluster was created using a 
Blueprint or not and used to determine to run Blueprint specific code or UI 
specific one in {{KerverosHelperImpl.setAuthToLocalRules}}.

This is the problematic bit that causes this bug. The problem is that when 
Ranger is added using the UI to a cluster that was originally created using 
Blueprint the {{cluster.isBluePrintDeployed()}} returns true when executed in 
{{KerverosHelperImpl.setAuthToLocalRules}} and the Blueprint specific branch of 
the {{if}} statement is executed. This is wrong as this is a service install 
from the UI !!!

Instead of relying on {{cluster.isBluePrintDeployed()}} we need to revisit why 
the differences between Blueprint and UI install and try to hook the invocation 
of {{KerverosHelperImpl.setAuthToLocalRules}} in such a way that unified logic 
can be executed which is agnostic to where a service component install was 
originated from.

It is actually unclear to me why this logic is relevant when determining the 
auth-to-local rules. If a service is installed no matter what the state or 
method of installation is, its auth-to-local rules should be considered. Was 
there an issue related to this?

Historically, maybe there was a perceived issue in that some services 
repeateadly thought their configs were stale, but I think that is fixed now 
that the rules should be consistently generated. Thus a cluster with an 
unchanged set of installed servce should always generate the same rule set.

- Robert

On July 8th, 2016, 3:21 p.m. EDT, Robert Levas wrote:

Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, Nate Cole, and 
Sebastian Toader.

By Robert Levas.

Updated July 8, 2016, 3:21 p.m.


Repository: ambari


When adding new services and components to a cluster that was initially created 
via Blueprints (rather than via the Ambari UI), auth-to-local rules that are 
expected to be created as indicated by the Kerberos descriptor are not.

It occurs because the components being installed are in the INIT state where 
the logic to determine whether to include the new auth-to-local rules or not 
expects the components to be in either the INSTALLED or STARTED states. This is 
due to logic added when resolving AMBARI-14232.


Allow for auth-to-local rules for new services and components to be added when 
the state of the components are INIT as well as INSTALLED and STARTED, when the 
cluster was installed via Blueprints.


Manually tested..

Local unit tests:

Running org.apache.ambari.server.controller.KerberosHelperTest Tests run: 63, 
Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.402 sec - in 

Previous existing and unrelated unit test error:

Running org.apache.ambari.server.state.ServicePropertiesTest Tests run: 1, 
Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.505 sec <<< FAILURE! - in 
 Time elapsed: 0.504 sec <<< ERROR! org.apache.ambari.server.AmbariException: 
 n-properties.xml didn't pass the validation. Error message is : 
cvc-complex-type.3.2.2: Attribute 'update' is not allowed to appear in element 
'on-ambari-upgrade'. at 

Jenkins unit tests: PENDING



View <https://reviews.apache.org/r/49826/diff/> 

Reply via email to