[
https://issues.apache.org/jira/browse/AMBARI-11659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Nettleton updated AMBARI-11659:
--------------------------------------
Attachment: AMBARI-11659.patch
Uploaded initial version of patch.
> 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)
