THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- configurations : A list of configuration maps keyed by configuration type. An example of a configuration type is "core-site". When specified at the top level, configurations are applied at cluster scope and override default values for the cluster. When specified within a "host_groups" element, configurations are applied at the host level for all hosts mapped to the host group. Host scoped configurations override cluster scoped configuration for all hosts mapped to the host group. The configurations element is optional at both levels.
- host_groups : A list of host groups which define topology (components) and configuration for all hosts which are mapped to the host group. At least one host group must be specified.
- name : The name of the host group. Mandatory field which is referred to in the cluster creation body when mapping physical hosts to host groups.
- components : A list of components which will run on all hosts that are mapped to the host group. At least one component must be specified for each host group.
- provision_action : Cluster wide provision action can be specified in Cluster Creation Template (see below), but optionally this can be overwritten on component level, by specifying a different provision_action here. The default provision_action is INSTALL_AND_START.
- cardinality : This field is optional and intended to provide a hint to the deployer as to how many instances of a particular host_group can be instantiated; it has no bearing on how the cluster is deployed. When a blueprint is exported for an existing cluster, this field will indicate the number of hosts that correspond the the host group in that cluster.
- Blueprints : Blueprint and stack information
- stack_name : The name of the stack. All stacks currently shipped with Ambari have the name "HDP". This is a required field.
- stack_version : The version of the stack. For example: "1.3.2" or "2.1". This is a required field. When deploying a cluster using a blueprint, the stack definition identified in the blueprint must be available to the Ambari instance in the new cluster.
- blueprint_name : Optional field which specifies that name of the blueprint. Typically the name of the blueprint is specified in the URL of the REST invocation. The only reason to specify the name in the blueprint is when creating multiple blueprints via a single REST invocation. Be aware that the name specified in this field will override the name specified in the URL.
- security : Optional block to specify security settings for blueprint. Supported security types are NONE and KERBEROS. In case of KERBEROS, users have the option to embed a valid kerberos descriptor - to override default values defined for HDP stack - in field kerberos_descriptor or as an alternative they may reference a previously saved kerberos descriptor using kerberos_descriptor_reference field.
In case of selecting KERBEROS as security_type it's mandatory to add kerberos-env and krb5-conf config types. (Checkout configurations section in Blueprint example with KERBEROS on this page)
Be aware that, Kerberos client packages needs to be installed on the host running Ambari server and krb5.conf needs to be configured properly to contain your realm (admin_server and kdc).
Automated Kerberization page describes structure of kerberos_descriptor.
settings: An optional section to provide additional configuration for cluster behavior during and after the blueprint deployment. You can provide configurations for the following properties:
recovery_settings: A section to specify if all services (globally) should be set with auto restart once the cluster is deployed. To configure it, specify "recover_enabled" property to either "true" (auto restart), or "false" (do not auto restart).
For example:
"settings": [
"recovery_settings":[
{
"recovery_enabled":"true"
}
]
],- service_settings: A section to specify if services should be set with auto restart once the cluster is deployed. To configure it, specify "recover_enabled" property to either "true" (auto restart), or "false" (do not auto restart).
For example:
"settings": [
"service_settings":[
{
"name":"HDFS",
"recovery_enabled":"true"
},
{
"name":"ZOOKEEPER",
"recovery_enabled":"true"
}
]
], - component_settings: A section to specify if components should be set with auto restart once the cluster is deployed. To configure it, specify "recover_enabled" property to either "true" (auto restart), or "false" (do not auto restart).
For example:
"settings": [
"component_settings":[
{
"name":"KAFKA_CLIENT"
"recover_enabled":"true"
},
{
"name":"METRICS_MONITOR",
"recover_enabled":"true"
}
]
], - deployment_settings: A section to specify if the blueprint deployment should auto skip install and start failures. To configure this behavior, specify "skip_failure" property to either "true" (auto skip failures), or "false" (do not auto skip failures). Blueprint deployment will fail on the very first deployment failure if the blueprint file does not contain the "deployment_settings" section.
For example:
"settings": [
"recovery_settings":[
{
"recovery_enabled":"true"
}
]
], repository_settings: A section to specify custom repository URLs for the blueprint deployment. This section allows you to provide custom URLs to override the default ones. Without this section, you will need to update the repository URLs via REST API before deploying the cluster with the blueprint. "override_strategy" can be "ALWAYS_APPLY" ( always override the default one), or "APPLY_WHEN_MISSING" (only add it if no repository exists with the specific operating system and the repository id information). Repository URLs stored in the Ambari server database will be used if the blueprint does not have the "repository_settings" section.
For example:
settings: [
"repository_settings":[
{
"override_strategy":"ALWAYS_APPLY"
"operating_system":"redhat7",
"repo_id":"HDP",
"base_url":"http://myserver/hdp"
},
{
"override_strategy":"APPLY_WHEN_MISSING",
"operating_system":"redhat7",
"repo_id":"HDP-UTIL-1.1",
"base_url":"http://myserver/hdp-util"
}
]
]
Cluster Creation Template Structure
...