Openstack orchestration program aims to create a human and machine-accessible service for managing the entire lifecycle of infrastructure and applications within OpenStack clouds, this is achieved by using HEAT.

HEAT is a project of Openstack, it implements an orchestration engine to launch multiple composite cloud applications based on templates in the form of text files that can be treated like code.

Managing Infrastructure using HEAT

1. A Heat template describes the infrastructure for a cloud application in a text file that is readable and writable. It can be checked into version control.
2. Heat manages the whole lifecycle of the application – when you need to change your infrastructure, simply modify the template and use it to update your existing stack. Heat knows how to make the necessary changes.
3. Infrastructure resources that can be described include: servers, floating ips, volumes, security groups, users, etc.
4. Templates can also specify the relationships between resources (e.g. this volume is connected to this server). This enables Heat to call out to the OpenStack APIs to create all of your infrastructure in the correct order to completely launch your application.
5. Heat primarily manages infrastructure, but the templates integrate well with software configuration management tools such as Puppet, Chef and Ansible.

Template Structure

HOT templates are defined in YAML and follow the structure outlined below.

 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

Heat Template Version

Each HOT template has to include the heat_template_version key with a valid version of HOT, e.g. 2015-10-15 (see Heat template version for a list of all versions).

 Description

The description is optional, it is good practice to include some useful text that describes what users can do with the template. In case you want to provide a longer description that does not fit on a single line, you can provide multi-line text in YAML, for example,

description: >
  This is how you can provide a longer description
  of your template that goes over several lines.

Parameter Groups

This section allows for specifying how the input parameters should be grouped and the order to provide the parameters in. This section is optional and can be omitted when necessary.

Parameters

This section allows for specifying input parameters that have to be provided when instantiating the template. The section is optional and can be omitted when no input is required.

parameters:
  key_name:
    type: string
    label: Key Name
    description: Name of key-pair to be used for compute instance.

Resources

This section contains the declaration of the single resources of the template. This section with at least one resource should be defined in any HOT template, or the template would not really do anything when being instantiated.

resources:
  my_instance:
    type: OS::Nova::Server
    properties:
      key_name: { get_param: key_name }
      image: { get_param: image_id }
      flavor: { get_param: instance_type }

 Outputs

This section allows for specifying output parameters available to users once the template has been instantiated. This section is optional and can be omitted when no output values are required.

outputs:
  instance_ip:
    description: The IP address of the deployed instance
    value: { get_attr: [my_instance, first_address] }

Autoscaling

Heat also provides an autoscaling service for groups of virtual servers.This is accessible by creating a Heat template containing the relevant resources ie. Scaling Group, Load Balancer Launch Config Policy, Alarm. The reference relationships between resources used to automatically scale a group of servers.

As shown in figure, a launch configuration (for new servers being added to the group), a scaling group, OpenStack Metering (Ceilometer) alarms and scaling policies. Scaling groups can also update a load balancer configuration when their membership changes. Ceilometer alarms call a webhook, the one provided by the scaling policy resource and a scaling policy will make adjustments to a scaling group based on this input and its own configuration.