[ https://issues.apache.org/jira/browse/AMBARI-24888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Balázs Bence Sári resolved AMBARI-24888. ---------------------------------------- Resolution: Fixed > 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)