You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by "Robert Nettleton (JIRA)" <ji...@apache.org> on 2015/06/03 18:27:38 UTC

[jira] [Updated] (AMBARI-11659) Blueprint processor filters should have better error handling for invalid configuration types

     [ https://issues.apache.org/jira/browse/AMBARI-11659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Nettleton updated AMBARI-11659:
--------------------------------------
           Component/s: ambari-server
           Description: 
The new Blueprint's filtering mechanism in the BlueprintConfigProcessor needs to handle exceptions/errors in a more graceful way.

Currently, if a Blueprint contains an invalid configuration type, this will cause the underlying Stack code to throw a RuntimeException. This in turn causes config processing to fail, and never reach the topology resolution stage.  A cluster in this state will likely fail, since it's configuration items never move beyond the "INITIAL" state, and don't have the correct topology updates in order for services to locate each other.  

The Blueprint internal filters should catch any RuntimeExceptions thrown by the Stack processing code, but should only log these exceptions.  Since Blueprints uses an asynchronous model now for config processing, these types of errors can only be logged, they cannot stop the overall process of a cluster deployment.  This should allow the cluster to at least startup properly, as long as the rest of the configuration is valid.

I'm working on a fix for this, and will submit a patch shortly. 
              Priority: Critical  (was: Major)
     Affects Version/s: 2.1.0
         Fix Version/s: 2.1.0
    Remaining Estimate: 24h
     Original Estimate: 24h

> Blueprint processor filters should have better error handling for invalid configuration types
> ---------------------------------------------------------------------------------------------
>
>                 Key: AMBARI-11659
>                 URL: https://issues.apache.org/jira/browse/AMBARI-11659
>             Project: Ambari
>          Issue Type: Bug
>          Components: ambari-server
>    Affects Versions: 2.1.0
>            Reporter: Robert Nettleton
>            Assignee: Robert Nettleton
>            Priority: Critical
>             Fix For: 2.1.0
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> The new Blueprint's filtering mechanism in the BlueprintConfigProcessor needs to handle exceptions/errors in a more graceful way.
> Currently, if a Blueprint contains an invalid configuration type, this will cause the underlying Stack code to throw a RuntimeException. This in turn causes config processing to fail, and never reach the topology resolution stage.  A cluster in this state will likely fail, since it's configuration items never move beyond the "INITIAL" state, and don't have the correct topology updates in order for services to locate each other.  
> The Blueprint internal filters should catch any RuntimeExceptions thrown by the Stack processing code, but should only log these exceptions.  Since Blueprints uses an asynchronous model now for config processing, these types of errors can only be logged, they cannot stop the overall process of a cluster deployment.  This should allow the cluster to at least startup properly, as long as the rest of the configuration is valid.
> I'm working on a fix for this, and will submit a patch shortly. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)