A quick introduction to OpenStack Heat.

An important component of a cloud environment is orchestration. In OpenStack, there is a program dedicated exclusively to Orchestration within the platform and the main project in this program is Heat. In this blog post, we will learn a little bit about OpenStack Heat (Heat from here on) and how to create simple orchestrations with it.

According to the OpenStack Foundation, Heat (https://wiki.openstack.org/wiki/Heat) is an orchestration engine to launch multiple composite cloud applications based on templates in the form of text files that can be treated as code. In simple terms, Heat provides the OpenStack users with a way to automate the creation of cloud components like networks, instances, storage devices and much more.

Heat Architecture Components

There are four (4) main components of the Heat project, each performing a unique function:

heat: is the CLI that communicates with the heat-api.

heat-api: is the component that provides an OpenStack-native ReST API that processes the requests and sends them to the heat-engine.

heat-api-cfn: this component provides an AWS-style Query API that is compatible with AWS CloudFormation and process the requests and send them to the heat-engine.

heat-engine: is the brains of the operation and does the main work of orchestrating the launch of templates and providing events back to the API consumer.

How it works

Now that we know what are the Heat components is time to understand how it works, to do that we need to introduce couple more concepts around Heat.

Resources: They are objects that will be created or modified during the orchestration. Resources could be networks, routers, subnets, instances, volumes, floating IPs, security groups and more.

Stack: In Heat, a stack is a collection of resources.

Parameters: Allow the user to provide input to the template during deployment. For example, if you want to input the name for an instance in an orchestration, that name could be input as a parameter in the template and change during each runtime.

Templates: Is how a Stack is defined and described with code.

Output: As the name indicates, outputs provide information back to the user.

Now that we understand the basic concepts around Heat, we could resume how it works.

1. The orchestration is defined in a template by describing the objects (resources) in a human readable format.
2. The user creates the “stack” by pointing the heat cli tool to the template file and parameters.
3. The heat-cli tool communicates with the heat-api.
4. The heat-api sends the request to the heat-engine.
5. The heat-engine process the request by talking to the other OpenStack APIs and provides output back to the user.

Templates

Now that we understand how it works, components and architecture let's dive in the templates. A Heat template is usually a YAML file and contains the following fields:

• Version
• Description
• Parameters
• Resources
• Output

Only three (3) of this fields are required to get a basic template: version, description, and resources. Here is an example of a basic template to create a simple nova flavor:

heat_template_version: 2016-10-14

description: Template to create a  Nova custom flavor.

resources: 
  nova_flavor:
    type: OS::Nova::Flavor
    properties:
      ephemeral: 1
      is_public: true
      name: custom-tiny.m1
      ram: 512
      vcpus: 1

As you may notice, we did not declare either parameters or outputs, and this template will be able to run and create a stack with one resource (nova_flavor).

To understand more on the template creation and best practices you should visit the template guide here.

And for more on Heat and OpenStack resources, you should check the OpenStack Heat Developer Guide at http://docs.openstack.org/developer/heat/template_guide/.

Hope that this introduction been useful to you and please remember to comment if you have any questions and share this post if you found it helpful.