Robert Nettleton created AMBARI-17151:
-----------------------------------------
Summary: Blueprint deployments fail when services manually removed
from stack definitions
Key: AMBARI-17151
URL: https://issues.apache.org/jira/browse/AMBARI-17151
Project: Ambari
Issue Type: Bug
Components: ambari-server
Affects Versions: 2.4.0
Reporter: Robert Nettleton
Assignee: Robert Nettleton
Priority: Critical
Fix For: 2.4.0
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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
