-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/48553/#review137057
-----------------------------------------------------------


Ship it!




Ship It!

- Robert Levas


On June 10, 2016, 3:09 p.m., Robert Nettleton wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48553/
> -----------------------------------------------------------
> 
> (Updated June 10, 2016, 3:09 p.m.)
> 
> 
> Review request for Ambari, Laszlo Puskas, Mahadev Konar, Oliver Szabo, Robert 
> Levas, Sandor Magyari, and Sumit Mohanty.
> 
> 
> Bugs: AMBARI-17151
>     https://issues.apache.org/jira/browse/AMBARI-17151
> 
> 
> Repository: ambari
> 
> 
> Description
> -------
> 
> This patch resolves AMBARI-17151. 
> 
> As detailed in AMBARI-17151, the BlueprintConfigurationProcessor was failing 
> during the configuration resolution phase.  This particular failure will only 
> occur when a user has removed a set of services from the Ambari Stack 
> definitions after the ambari-server install, and a component in the specified 
> Blueprint for this deployment includes an "excluded" configuration type 
> reference to a removed service.
> 
> In the past, the Blueprint processor operated under the assumption that the 
> stacks were static in nature.  This patch allows the Blueprint configuration 
> processor to be more lenient when changes like this are made to the stacks in 
> a custom environment.  
> 
> This patch implements the following:
> 
> 1. Updates the "addExcludedConfigProperties" method in the 
> BlueprintConfigurationProcessor to detect the case where an excluded 
> configuration type exists for a service that the stack definitions do not 
> include.  Currently, this can only occur if custom changes (removal of 
> service(s)) are made to the stack definitions. 
> 2. When this exceptional case is encountered, the 
> BlueprintConfigurationProcessor will now log a message, indicating that no 
> matching service is found for the given excluded configuration type, and that 
> this is likely caused by a change in the stack definitions.  The logged 
> message will probably also be useful in the future to debug errors in new 
> stack definitions. 
> 3. Implements a unit test to verify this change.
> 
> 
> Diffs
> -----
> 
>   
> ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessor.java
>  de70a2c 
>   
> ambari-server/src/test/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessorTest.java
>  9ec0a09 
> 
> Diff: https://reviews.apache.org/r/48553/diff/
> 
> 
> Testing
> -------
> 
> 1. Verified that a deployment of a Blueprint for a 3-node HDFS HA cluster 
> will work properly, even after manually removing the "STORM" service from all 
> stacks in the ambari-server install.  Since Metrics has an excluded 
> configuration reference to Storm, this verifies the original problem. With 
> this patch applied, the cluster deploys properly, without the configuration 
> exception mentioned in the associated bug JIRA. 
> 
> 2. Ran "mvn clean test" with my patch applied to trunk:
> 
> 
> "
> Results :
> 
> Tests in error:
>   AmbariMetaInfoTest.testCrossCheckJmxToGangliaMetrics:941 » Provision Guice 
> pro...
>   KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » 
> Provision G...
>   KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » 
> Provision G...
>   KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » 
> Provision G...
>   StackManagerTest.testMetricsLoaded:669 » Ambari Stack Definition Service at 
> '/...
>   StackManagerTest.testServicesWithLogsearchRoleCommandOrder:820 » Ambari 
> Stack ...
>   StackManagerTest.testServicesWithRangerPluginRoleCommandOrder:713 » Ambari 
> Sta...
> 
> Tests run: 4473, Failures: 0, Errors: 7, Skipped: 34
> "
> 
> Note:  There were 7 errors during this run, but I verified that these 
> failures occur on trunk without my patch applied, so these failures are not 
> caused by this current patch.
> 
> 3. Ran "mvn clean test" with this morning's latest trunk src, with this patch 
> applied, and the full suite passed:
> 
> "Results :
> 
> Tests run: 4477, Failures: 0, Errors: 0, Skipped: 34"
> 
> 
> Thanks,
> 
> Robert Nettleton
> 
>

Reply via email to