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

(Updated June 10, 2016, 3:39 p.m.)

Review request for Ambari, Laszlo Puskas, Mahadev Konar, Oliver Szabo, Sandor 
Magyari, and Sumit Mohanty.

Bugs: AMBARI-17151

Repository: ambari


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 
3. Implements a unit test to verify this change.



Diff: https://reviews.apache.org/r/48553/diff/

Testing (updated)

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 
  KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » Provision 
  KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » Provision 
  KerberosServiceMetaInfoTest.before:160->createAmbariMetaInfo:211 » Provision 
  StackManagerTest.testMetricsLoaded:669 » Ambari Stack Definition Service at 
  StackManagerTest.testServicesWithLogsearchRoleCommandOrder:820 » Ambari Stack 
  StackManagerTest.testServicesWithRangerPluginRoleCommandOrder:713 » Ambari 

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"


Robert Nettleton

Reply via email to