ambari-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Nettleton (JIRA)" <j...@apache.org>
Subject [jira] [Created] (AMBARI-17151) Blueprint deployments fail when services manually removed from stack definitions
Date Thu, 09 Jun 2016 20:43:21 GMT
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)

Mime
View raw message