[
https://issues.apache.org/jira/browse/AMBARI-24888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16686397#comment-16686397
]
Hudson commented on AMBARI-24888:
---------------------------------
SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #10288 (See
[https://builds.apache.org/job/Ambari-trunk-Commit/10288/])
AMBARI-24888 fix SingleHostTopologyUpdater (benyoka) (#2603) (github:
[https://gitbox.apache.org/repos/asf?p=ambari.git&a=commit&h=6395167a5a74d44b9d86dabeb2c0860df450ec67])
* (edit)
ambari-server/src/main/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessor.java
* (edit)
ambari-server/src/test/java/org/apache/ambari/server/controller/internal/BlueprintConfigurationProcessorTest.java
> Fix SingleHostTopologyUpdater
> -----------------------------
>
> Key: AMBARI-24888
> URL: https://issues.apache.org/jira/browse/AMBARI-24888
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
> Affects Versions: 2.7.1
> Reporter: Balázs Bence Sári
> Assignee: Balázs Bence Sári
> Priority: Critical
> Labels: pull-request-available
> Fix For: trunk
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Newer Ambari installations often require clusters with partially installed
> services (some required components missing). These clusters typically connect
> to other clusters and use some of the services from the external cluster.
> Ambari provides support for this by accepting blueprints with
> {{validate_topology=false}} flag, however the support is incomplete as
> usually exceptions are thrown later during the installation process with such
> blueprints.
> Most of the exceptions are thrown in the {{SingleHostTopologyUpdater}} class
> which acts as a validator in addition to being a property updater.
> The property update logic in {{SingleHostTopologyUpdater}} is the following:
> * All {{SingleHostTopologyUpdater}} instances are associated with a component
> (e.g. NAMENODE)
> * first, it does {{%HOSTGROUP%}} token replacement by calling the
> supertclas's method. *If this is successful, the replaced value is returned
> without any validation* (even with invalid topology)
> * if there is only one matching hostgroup for the updater's associated
> component, *validation will be skipped too*. If the property's value contains
> {{localhost}}, it will be replaced with the FQDN of one of the host from the
> matching host groups.
> * In all other cases, a validation process starts which tries to match a
> sequence of valid cases with the actual topology. If one of the cases match,
> the property will be returned unchanged. In none matches, an exception is
> thrown.
> As it can be seen above, the validation logic is not completely consistent.
> There are cases where validation is bypassed. E.g. if the updater encounters
> a {{%HOSTROUP%}} token, it will do the replacement even if the topology is
> broken and the associated component is missing.
> *Proposed solution*
> Features:
> * A general solution
> * Still protects from accidentally broken topology
> * Permits properties to point to external services
> * Very easy to implement (just a few lines).
> The proposed solution would simply leave the update logic in
> {{SingleHostTopologyUpdater}} as is and would restrict validation for the
> cases when the property contains {{localhost}}. This latter indicates that
> the property has the stack default value.
> This way, validation would still be performed in most cases when a component
> is left out from the blueprint by mistake.
> However, when a component is left out intentionally and the respective
> properties are intentionally set to point to an external FQDN or set to empty
> values, validation would be skipped.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
