[AMBARI-17151] Blueprint deployments fail when services manually removed from stack definitions

• Type: Bug
• Status: Resolved
• Priority: Critical
• Resolution: Fixed
• Affects Version/s: 2.4.0
• Fix Version/s: 2.4.0
• Component/s: ambari-server
• Assignee: Bob Nettleton
• Reporter: Bob Nettleton
• Created: 09/Jun/16 20:43
• Updated: 10/Jun/16 23:53
• Resolved: 10/Jun/16 21:26

Description

In certain custom use cases, an Ambari user may choose to customize the Ambari stack definitions by manually removing services.

This can cause some failures during a Blueprint deployment, particularly in the area of "excluded" configurations.

When an "excluded" configuration type is found, the Blueprint processor attempts to add this configuration, and queries the Stack APIs to determine the service associated with this configuration type.

If this particular service has been manually deleted from the stacks, the Stack APIs will throw a runtime exception, which causes the entire Blueprint deployment to fail.

Example:

If Ambari Metrics is included in a Blueprint, the "storm-site" configuration type is considered an "excluded-configuration" by the stack definitions. In this case, if the "STORM" service definitions have been removed, then the following exception will result when a cluster deployment based on a Blueprint is attempted:

java.lang.IllegalArgumentException: Specified configuration type is not associated with any service: storm-site
at org.apache.ambari.server.controller.internal.Stack.getServiceForConfigType(Stack.java:485)
at org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.addExcludedConfigProperties(BlueprintConfigurationProcessor.java:2781)
at org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.setMissingConfigurations(BlueprintConfigurationProcessor.java:2751)
at org.apache.ambari.server.controller.internal.BlueprintConfigurationProcessor.doUpdateForClusterCreate(BlueprintConfigurationProcessor.java:335)
at org.apache.ambari.server.topology.ClusterConfigurationRequest.process(ClusterConfigurationRequest.java:153)
at org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:780)
at org.apache.ambari.server.topology.TopologyManager$ConfigureClusterTask.call(TopologyManager.java:754)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
...

In these custom deployments, the Blueprints processor should be more lenient with respect to error handling.

If a matching service is not found for a given "excluded" configuration type, the Blueprint processor should log this as a WARNING, indicating that the stacks have likely been modified outside of Ambari.

I'm working on a fix for this, and will be submitting a patch soon.

Issue Links

• links to: ReviewBoard