Heat Orchestration Template (HOT) specification

1. Template structure1.1 Status

Hot is a new template format that replaces Heat cloudformation-compatible format (CFN), and heat has started to support multiple versions of hot since Juno version

1.2 Template format

The hot template style is defined by YAML in the following form:

Heat_template_version:2015-04-30

Description

# A description of the template

Parameter_groups:

# A declaration of input parameter groups and order

Parameters

# Declaration of input parameters

Resources

# Declaration of template Resources

Outputs

# Declaration of output parameters

1. Heat_template_version

1. Description

Optional keywords, template description

1. Parameter_groups

Optional keywords, grouping input parameters and providing parameter order

1. Parameters

Optional keywords, specifying input parameters when initializing a template

1. Resources

Define the resources in the template, this module must define at least one resource, otherwise the initialization template is invalid

1. Outputs

Optional keyword specifying the output parameters that the user can get after the template initialization is complete

1.2.1 Heat Template version

The parameter illustrates that the Yaml file is a specific version of the hot template and also identifies the features that the template validates and supports. Currently Heat supports the following heat template version keywords, each of which features are supported by:

2013-05-23

Get_attr	Get_file	Get_param	Get_resource
List_join	Resource_facade	Str_replace	Fn::base64
Fn::getazs	Fn::join	Fn::memberlisttomap	Fn::replace
Fn::resourcefacade	Fn::select	Fn::split	Ref

2014-10-16

Get_attr	Get_file	Get_param	Get_resource
List_join	Resource_facade	Str_replace	Fn::select

2015-04-30

Get_attr	Get_file	Get_param	Get_resource
List_join	Resource_facade	Str_replace	Repeat
Fn::select

2015-10-15

Get_attr	Get_file	Get_param	Get_resource
List_join	Resource_facade	Str_replace	Repeat
Fn::select	Digest	Str_split

1.2.2 Parameter Groups Section

The module format is:

Parameter_groups:

-Label:

Description: <description of the parameter group>

Parameters

-<param name>

-<param name>

Label: Parameter group label Description: Parameter group description parameters: Parameter list param name: parameter name, associated with the parameter defined in the Parameters module

1.2.3 Parameters Section

The module format is:

Parameters

<param Name>:

Type: <string | number | JSON | Comma_delimited_list | Boolean>

Label:

Description: <description of the Parameter>

Default: <default value for parameter>

Hidden: <true | False>

Constraints

<parameter constraints>

PARAM name: Parameter First Name type: parameter type

Type	Description	Examples
String	A literal string.	"String param"
Number	An integer or float.	"2"; "0.2"
comma_delimited_list	An array of literal strings that is separated by commas. The total number of strings should is one more than the total number of commas.	["One", "both"]; "One, the other"; Note: "One, both" returns ["one", "one", "one"]
JSON	A json-formatted map or Lis T.	{"Key": "Value"}
Boolean	Boolean type value, which C An IS equal "T", "true", "on", "Y", "yes", or "1" for true Value and "F", "false", "Off", "N", "No", or "0" for false valu E.	"on"; "N

Label: Optional keyword, parameter label description: Optional keyword, parameter description default: Optional keyword, parameter defaults hidden: whether the parameter needs to be hidden when you view the stack information created by the template with a request, Default falseconstraints: Optional keyword, constraint list, validated by Orchestration Engine when user deploys stack

The constraint module format is:

Constraints

-<constraint type>: <constraint definition>

Description: <constraint description>

Description: Optional keyword, constraint description

Constrains type: Constraint type

Constraint definition: The constraint content, the corresponding relationship with the type is as follows

Constraint type	Constraint Object	Constraint content
Length	String	Length: {min: <lower limit>, max: <upper limit>}
Range	Number	Range: {min: <lower limit>, max: <upper limit>}
Allowed_values	String or number	Allowed_values: [<value>, <value>, ...]
Allowed_pattern	String	Allowed_pattern: <regular expression>
Custom_constraint	Check if a specific resource exists The resource list is as follows	Custom_constraint: <name>
Pseudo parameters	Stack	Os::stack_name os::stack_id OS::p roject_id

The following section lists the custom constraints and the Plug-ins, the support them.

Name	Plug-in
Cinder.backup	Heat.engine.clients.os.cinder:VolumeBackupConstraint
Cinder.snapshot	Heat.engine.clients.os.cinder:VolumeSnapshotConstraint
Cinder.volume	Heat.engine.clients.os.cinder:VolumeConstraint
Cinder.vtype	Heat.engine.clients.os.cinder:VolumeTypeConstraint
Cron_expression	Heat.engine.constraint.common_constraints:CRONExpressionConstraint
Designate.domain	Heat.engine.clients.os.designate:DesignateDomainConstraint
Glance.image	Heat.engine.clients.os.glance:ImageConstraint
Ip_addr	Heat.engine.constraint.common_constraints:IPConstraint
iso_8601	Heat.engine.constraint.common_constraints:ISO8601Constraint
Keystone.domain	Heat.engine.clients.os.keystone:KeystoneDomainConstraint
Keystone.group	Heat.engine.clients.os.keystone:KeystoneGroupConstraint
Keystone.project	Heat.engine.clients.os.keystone:KeystoneProjectConstraint
Keystone.role	Heat.engine.clients.os.keystone:KeystoneRoleConstraint
Keystone.service	Heat.engine.clients.os.keystone:KeystoneServiceConstraint
Keystone.user	Heat.engine.clients.os.keystone:KeystoneUserConstraint
Mac_addr	Heat.engine.constraint.common_constraints:MACConstraint
Manila.share_network	Heat.engine.clients.os.manila:ManilaShareNetworkConstraint
Manila.share_snapshot	Heat.engine.clients.os.manila:ManilaShareSnapshotConstraint
Manila.share_type	Heat.engine.clients.os.manila:ManilaShareTypeConstraint
Monasca.notification	Heat.engine.clients.os.monasca:MonascaNotificationConstraint
Net_cidr	Heat.engine.constraint.common_constraints:CIDRConstraint
Neutron.network	Heat.engine.clients.os.neutron:NetworkConstraint
Neutron.port	Heat.engine.clients.os.neutron:PortConstraint
Neutron.router	Heat.engine.clients.os.neutron:RouterConstraint
Neutron.subnet	Heat.engine.clients.os.neutron:SubnetConstraint
Nova.flavor	Heat.engine.clients.os.nova:FlavorConstraint
Nova.keypair	Heat.engine.clients.os.nova:KeypairConstraint
Nova.network	Heat.engine.clients.os.nova:NetworkConstraint
Nova.server	Heat.engine.clients.os.nova:ServerConstraint
Sahara.image	Heat.engine.clients.os.sahara:ImageConstraint
Sahara.plugin	Heat.engine.clients.os.sahara:PluginConstraint
TimeZone	Heat.engine.constraint.common_constraints:TimezoneConstraint
Trove.flavor	Heat.engine.clients.os.trove:FlavorConstraint

1.2.4 Resources Section

Module format:

Resources

<resource Id>:

Type: <resource type>

Properties

<property name>: <property value>

Metadata

<resource specific metadata>

DEPENDS_ON: <resource ID or List of id>

Update_policy: <update policy>

Deletion_policy: <deletion policy>

Resource ID: The unique type within the template: resource type, such as Os::nova::server or Os::neutron::P ortproperties: Optional keyword, resource attribute list, property value can be provided directly, or through a function (see later in the inner function) metadata: Optional keyword, metadata depends_on: Optional keyword, resource dependency

Application Example: When a resource relies on one or more resources,

Resources

Server1:

Type:os::nova::server

DEPENDS_ON: [Server2, Server3]

Server2:

Type:os::nova::server

Server3:

Type:os::nova::server

Update_policy: Optional keyword, resource update policy, whether update policy is supported, and exact semantics depend on resource type deletion_policy: Optional keyword, optional keyword, resource deletion policy, supported delete policy type depending on resource type

1.2.5 Outputs Section

Module format:

Outputs

<parameter Name>:

Description: <description>

Value: <parameter value>

Parameter name: output parameter name, template within the unique description: Optional parameter, output parameter description parameter value: Output parameter value, usually obtained by the function (internal function see later)

2. Intrinsic functions

Note: These function values can be used for the resource properties module, or the output module

2.1 get_attr: Referencing resource properties

Keyword-or index-based methods require heat_template_version 2014-10-16 or higher

After 2015-10-15,<attribute_name> is an optional keyword, the default is all attributes

Get_attr:

-<resource name>

-<attribute name>

-<key/index 1> (optional)

-<key/index 2> (optional)

- ...

2.2 Get_file: Returns the contents of file in template

The argument must be a static path or URL and cannot depend on an intrinsic function

Get_file: <content key>d

2.3 Get_param: Input parameters for reference templates

Get_param:

-<parameter name>

-<key/index 1> (optional)

-<key/index 2> (optional)

- ...

2.4 Get_resource: Referencing other resource in the same template

Get_resource: <resource id>

2.5 List_join: Add the given delimiter to the strings list

List_join:

-<delimiter>

-<list to Join>

2.6 Str_split:list_join The opposite operation

Str_split:

- ‘,‘

-String,to,split

2.7 Digest: Digest operation on a given value

Kilo version introduced, version available after 2015-04-30

Algorithm provided by Hashlib (MD5, SHA1, sha224, SHA256, sha384, and sha512), or OpenSSL

Digest

-<algorithm>

-<value>

2.8 Repeat: Dynamically change the contents of the template resource list to return a new list

List content can come from a function

Repeat

Template

<template>

For_each:

<var>: <list>

2.9 Resource_facade: Extracting data from a parent template

Resource_facade: <data type>

2.10 str_replace: Replace the corresponding content in the template with the given value

Str_replace:

Template: <template string>

Params: <parameter mappings>

Heat Orchestration Template (HOT) specification