Overview
Prior to IOP 4.2.5, Apache Ambari has had support for declaring static dependency between components. This dependency is defined in service’s metainfo file. However, in some cases, the dependency between components is conditional where one component may be dependent on another component only under certain conditions. For example, In a hadoop cluster in case of Namenode High Availability, component Namenode has dependency over a component ZKFC. This is conditional dependency because when a Namenode High availability is not active, Namenode does not depend on component ZKFC. Ambari now supports conditional dependency between components.
To enforce conditional dependencies between components across services, support has been added in IOP version 4.2.5, Apache Ambari version 2.4.2. Currently this functionality is only exposed during blueprint validation phase. During blueprint deployment Ambari can optionally validate a blueprint provided to verify if the dependent components are also present in the blueprint. After adding support for conditional dependencies defined in service’s metainfo, blueprint validation has also been updated to honor conditional dependencies. This validation makes blueprint deployments more robust avoiding running into error situations when the blueprint did not contain correct component information.
Working with Conditional Dependency
Ambari uses configuration explicitly defined in the blueprint to evaluate dependency conditions that are declared in Service definition and determines if the component are dependent. Ambari validates blueprint against all the evaluated conditional dependencies and throws validation error if a conditionally dependent component is not present in the blueprint. Blueprint validation is applied on set of combined dependencies resulted from application of service and stack inheritance rules.
Ambari service developer needs to specify conditions in the service’s metainfo.xml file. During blueprint registration, Ambari scans the blueprint to check if there are any conditional dependencies present for every component listed in the blueprint. Based on configuration passed in the blueprint Ambari evaluates which conditions satisfy. For any component if all the conditions in service definition are satisfied then Ambari assumes that dependency is present; otherwise Ambari will consider that there is no dependency between the components.
Ambari currently supports two types of conditions.
1. Conditional dependency based on existence of certain property
Ambari detects if a property is present in the blueprint, if the property is present, the component dependency satisfies the condition and hence Ambari validates blueprint against that dependency. If the property is not present, dependency does not satisfy the condition, therefore Ambari will ignore the declaration of dependency and will not throw validation error even if the other component is not present in the blueprint.
To add this type of dependency condition user should insert a section ‘condition‘ under dependencies with attribute “xsi:type=’propertyExists’” and include ‘config-type‘ and ‘property_name‘ properties in the service definition file. Considering above example of Namenode HA dependency requirements, user needs to define condition section in ‘../HDFS/metainfo.xml’ file in the following way
In this example, Ambari scans blueprint to see if property ‘dfs.nameservices’ is present under config-type ‘hdfs-site’ in blueprint; if yes, then Ambari assumes that the dependency condition is satisfied and component NAMENODE has a dependency on component ZKFC. Hence Ambari checks if the component ZKFC is present in the component list of HostGroups to which component NAMENODE belongs. Ambari will throw a validation exception if ZKFC component is not present.
If the property ‘dfs.nameservices’ or config-type ‘hdfs-site’ is not present in the blueprint then Ambari assumes that NAMENODE component is not dependent in component ZKFC.
2. Conditional dependency based on value of certain property
In this dependency condition, if a certain property in the blueprint has a value mentioned in the service metainfo.xml file, then this condition satisfies. In that case, Ambari validates blueprint against the dependency. If the property is not present or has a different value, dependency does not satisfy the condition, therefore Ambari ignores the dependency.
To add this type of dependency condition user should insert section ‘condition‘ under dependencies with attribute “xsi:type=’propertyValueEquals’” and include ‘config-type‘, ‘property_name‘ and ‘propertyValue‘ properties in the service definition file. To understand an example of this condition type let us say that ‘DummyComponent1’ depends on ‘DummyComponent2’ when the values of ‘DummyProperty’ in ‘DummyConfigGroup’ is ‘true’. Service definition would be as follows
Inside the ‘conditions‘ tag, multiple ‘condition‘ tags can be declared. User can declare both types of conditions together or use same condition type multiple times under the ‘conditions‘ tag. These ‘condition‘ tags may all be of “xsi:type=’propertyValueEquals’” or “xsi:type=’propertyExists’” or mix of both cases.
Tag names details:
condition : This declares type of condition. Currently supported options: propertyExists, propertyValueEquals
configType : config-type within which the property is found. Ex – hdfs-site, hive-env, core-site
property : Property name Ex – dfs.nameservices
propertyValue : Value of the property Ex – true, false, 10, “aString”
Summary
This post describes the usage of conditional dependencies newly introduced in IOP version 4.2.5, Apache Ambari version 2.4.2. This feature allows us to effectively declare dependency between components dynamically on specific cluster deployment requirements. Combining this feature with the new Dynamic stack extensions – install and upgrade support for custom services (https://issues.apache.org/jira/browse/AMBARI-12885) feature also available in IOP 4.2.5, Ambari custom service developers have a powerful way to control how their service is installed in the cluster.