[
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)
