Details
-
Task
-
Status: Resolved
-
Critical
-
Resolution: Fixed
-
2.7.1
Description
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.
Attachments
Issue Links
- links to
