ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMBARI-11659) Blueprint processor filters should have better error handling for invalid configuration types
Date Thu, 04 Jun 2015 00:39:39 GMT

    [ https://issues.apache.org/jira/browse/AMBARI-11659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14571908#comment-14571908
] 

Hudson commented on AMBARI-11659:
---------------------------------

SUCCESS: Integrated in Ambari-trunk-Commit #2803 (See [https://builds.apache.org/job/Ambari-trunk-Commit/2803/])
AMBARI-11659. Blueprint processor filters should have better error handling for invalid configuration
types. (rnettleton) (rnettleton: http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=d59c24becc5ec553ef2dae23056b9d3beafde697)
* ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessor.java
* ambari-server/src/test/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessorTest.java


> 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
>
>         Attachments: AMBARI-11659.patch
>
>   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)

Mime
View raw message