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: https<https://reviews.apache.org/r/49826/>://<https://reviews.apache.org/r/49826/>reviews.apache.org<https://reviews.apache.org/r/49826/>/r/49826/<https://reviews.apache.org/r/49826/> On July 10th, 2016, 3:12 a.m. EDT, Sebastian Toader wrote: ambari<https://reviews.apache.org/r/49826/diff/1/?file=1439863#file1439863line900>-server/<https://reviews.apache.org/r/49826/diff/1/?file=1439863#file1439863line900>src<https://reviews.apache.org/r/49826/diff/1/?file=1439863#file1439863line900>/main/<https://reviews.apache.org/r/49826/diff/1/?file=1439863#file1439863line900>java<https://reviews.apache.org/r/49826/diff/1/?file=1439863#file1439863line900>/org/<https://reviews.apache.org/r/49826/diff/1/?file=1439863#file1439863line900>apache<https://reviews.apache.org/r/49826/diff/1/?file=1439863#file1439863line900>/<https://reviews.apache.org/r/49826/diff/1/?file=1439863#file1439863line900>ambari<https://reviews.apache.org/r/49826/diff/1/?file=1439863#file1439863line900>/server/controller/<https://reviews.apache.org/r/49826/diff/1/?file=1439863#file1439863line900>KerberosHelperImpl.java<https://reviews.apache.org/r/49826/diff/1/?file=1439863#file1439863line900> (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. Bugs: AMBARI<https://issues.apache.org/jira/browse/AMBARI-17629>-17629<https://issues.apache.org/jira/browse/AMBARI-17629> Repository: ambari Description 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. Solution: 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. Testing 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 org.apache.ambari.server.controller.KerberosHelperTest 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 org.apache.ambari.server.state.ServicePropertiesTest validatePropertySchemaOfServiceXMLs(org.apache.ambari.server.state.ServicePropertiesTest) Time elapsed: 0.504 sec <<< ERROR! org.apache.ambari.server.AmbariException: File /Users/rlevas/git/ambari/ambari-server/target/test-classes/TestAmbaryServer.samples/../../../src/main/resources/common-services/RANGER/0.4.0/configuration/admi 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 org.apache.ambari.server.state.ServicePropertiesTest.validatePropertySchemaOfServiceXMLs(ServicePropertiesTest.java:48) Jenkins unit tests: PENDING Diffs ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java (cc48240)ambari-server/src/test/java/org/apache/ambari/server/controller/KerberosHelperTest.java (66ed68d) View <https://reviews.apache.org/r/49826/diff/> Diff<https://reviews.apache.org/r/49826/diff/>
