Page History

...

Services MUST provide the main metainfo.xml file which provides important metadata about the service. 
Apart from that, other files can be provided to give more information about the service. More details about these files are provided below.

A service may also inherit from either a previous stack version or common services.  For more information see the Service Inheritance page.

metainfo.xml

In the metainfo.xml service descriptor, one can first define the service and its components.

...

• config-type - String representing a group of configurations. Example: core-site, hdfs-site, yarn-site, etc. When configurations are saved in Ambari, they are persisted within a version of config-type which is immutable. If you change and save HDFS core-site configs 4 times, you will have 4 versions of config-type core-site. Also, when a service's configs are saved, only the changed config-types are updated.
• configFiles - lists the config-files handled by the enclosing component
• configFile - represents one config-file of a certain type
  
  • type - type of file based on which contents are generated differently
    
    • xml - XML file generated in Hadoop friendly format. Ex: hdfs-site.xml
    • env - Generally used for scripts where the content value is used as a template. The template has config-tags whose values are populated at runtime during file generation. Ex: hadoop-env.sh
    • properties - Generates property files where entries are in key=value format. Ex: falcon-runtime.properties
  • dictionaryName - Name of the config-type as which key/values of this config file will be stored
• configuration-dependencies - Lists the config-types on which this component or service depends on. One of the implications of this dependency is that whenever the config-type is updated, Ambari automatically marks the component or service as requiring restart. From the code section above, whenever core-site is updated, both HDFS service as well as HDFS_CLIENT component will be marked as requiring restart.
• configuration-dir - Directory where files listed in configFiles will be. Optional. Default value is configuration.

Adding new configs in a config-type

There are a number of different parameters that can be specified to a config item when it is added to a config-type. These have been covered here. 

UI - Categories

Configurations defined above show up in the service's Configs page.

...

Read more about Ambari Alerts framework here in the Alerts wiki page and the alerts.json format in the Alerts definition documentation.

Kerberos

Ambari is capable of enabling and disabling Kerberos for a cluster. To inform Ambari of the identities and configurations to be used for the service and its components, each service can provide a kerberos.json file.

Read more about the Kerberos support and the Kerberos Descriptor in the Automated Kerberization wiki page and the Kerberos descriptor in the Kerberos Descriptor documentation.

Metrics

Ambari provides the Ambari Metrics System ("AMS") service for collecting, aggregating and serving Hadoop and system metrics in Ambari-managed clusters.

...

• versions/active - Whether this stack-version is still available for install. If not available, this version will not show up in UI during install.
• extends - The stack-version in this stack that is being extended. Extended stack-versions inherit services along with almost all aspects of the parent stack-version.
• minJdk - Minimum JDK with which this stack-version is supported. Users are warned during installer wizard if the JDK used by Ambari is lower than this version.
• maxJdk - Maximum JDK with which this stack-version is supported. Users are warned during installer wizard if the JDK used by Ambari is greater than this versionversion.

Stack Properties

The stack must contain or inherit a properties directory which contains two files: stack_features.json and stack_tools.json.  This directory is new in Ambari 2.4.

The stack_features.json contains a list of features that are included in Ambari and allows the stack to specify which versions of the stack include those features.  The list of features are determined by the particular Ambari release.  The reference list for a particular Ambari version should be found in the HDP/2.0.6/properties/stack_features.json in the branch for that Ambari release.  Each feature has a name and description and the stack can provide the minimum and maximum version where that feature is supported.

{

  "stack_features": [

    {

      "name": "snappy",

      "description": "Snappy compressor/decompressor support",

      "min_version": "2.0.0.0",

      "max_version": "2.2.0.0"

    },

    ...

}

The stack_tools.json includes the name and location where the stack_selector and conf_selector tools are installed.

{

  "stack_selector": ["hdp-select", "/usr/bin/hdp-select", "hdp-select"],

  "conf_selector": ["conf-select", "/usr/bin/conf-select", "conf-select"]

}

Any custom stack must include these two JSON files.  For further information see the Stack Properties wiki page.

Services

Each stack-version includes services which are either referenced from common-services, or defined inside the stack-version's services folder. 
Services are defined in common-services if they will be shared across multiple stacks. If they will never be shared, then they can be defined inside the stack-version.

...

• Stack Advisor interface
• Default Stack Advisor implementation - for all stacks
• HDP (2.0.6) Default Stack Advisor implementation
• YARN container size calculated
• Recommended configurations - HDFS, YARN, MapReduce2, HBase (HDP-2.0.6), HBase (HDP-2.3)
• Delete HBase Bucket Cache configs on smaller machines
• Specify maximum value for Tez config

Properties

Similar to stack configurations, most properties are defined at the service level, however there are global properties which can be defined at the stack-version level affecting across all services.
Some examples are: stack-selector and conf-selector specific names or what stack versions certain stack features are supported by. Most of these properties were introduced in Ambari 2.4 version in the effort of parameterize stack information and facilitate the reuse of common-services code by other distributions.

Such properties can be defined in .json format in the properties folder of the stack. 

More details about stack properties can be found on Stack Properties section.

Widgets

At the stack-version level one can contribute heatmap entries to the main dashboard of the cluster.
Generally these heatmaps would be ones which apply to all services - like host level heatmaps.
Example: HDP-2.0.6 contributes host level heatmaps 

...