You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ambari.apache.org by "Robert Nettleton (JIRA)" <ji...@apache.org> on 2016/06/09 20:43:21 UTC

[jira] [Created] (AMBARI-17151) Blueprint deployments fail when services manually removed from stack definitions

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)