> On July 10, 2016, 3:12 a.m., Sebastian Toader wrote: > > ambari-server/src/main/java/org/apache/ambari/server/controller/KerberosHelperImpl.java, > > line 900 > > <https://reviews.apache.org/r/49826/diff/1/?file=1439863#file1439863line900> > > > > 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 ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/49826/#review141603 ----------------------------------------------------------- On July 8, 2016, 3:21 p.m., Robert Levas wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/49826/ > ----------------------------------------------------------- > > (Updated July 8, 2016, 3:21 p.m.) > > > Review request for Ambari, Alejandro Fernandez, Jonathan Hurley, Nate Cole, > and Sebastian Toader. > > > Bugs: AMBARI-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. > > > 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 > > Diff: https://reviews.apache.org/r/49826/diff/ > > > 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/admin-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 > > > Thanks, > > Robert Levas > >
