Balázs Bence Sári created AMBARI-24888:
------------------------------------------

             Summary: 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
             Fix For: trunk


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)

Reply via email to