If you have followed some of my past work, you know I have a thing for automation and orchestration. Needless, I was super excited when I discovered OpenStack Orchestration (aka Heat).

Don’t know what Heat is? The OpenStack Wiki page has a great explanation:

Heat is the main project in the OpenStack Orchestration program. 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. A native Heat template format is evolving, but Heat also endeavours to provide compatibility with the AWS CloudFormation template format, so that many existing CloudFormation templates can be launched on OpenStack. Heat provides both an OpenStack-native ReST API and a CloudFormation-compatible Query API.

In fact the Heat documentation is ok in most areas: http://docs.openstack.org/developer/heat/getting_started/index.html

Note: The example below uses Rackspace Cloud. In order to adjust this to work with Devstack some changes will need to be made (changing the flavors, etc).

Building a Simple OpenStack Heat Template

Heat Templates use a format conveniently called the Heat Orchestration Template or HOT. It’s important to note that at this time, HOT is still under active development. For the template, I decided to draw on my earlier work with SpiderFoot here. To get started, open your favorite text editor, and paste this YAML in. Once you have it in, I’ll describe it a bit:

 

• 1: specifies the HOT template version. When reviewing third party templates, you can use this to see if said template is compatible with the version of Heat you have deployed.
• 3 – 4: The description. Not required but a really good practice. the | character allows it to be split onto multiple lines
• 6 – 39: Parameters. These lines specify various bits of input that are required when spinning a thing up from a HOT template.
• 6: Opens the parameters clause
• 8 – 15: Opens the “server_name” parameter. The name here is arbitrary, but should be self descriptive and consistent throughout
  • 9: Provides the variable type for ‘server_name’, in this case, a string
  • 10: A description
  • 11: default – allows us to specify a default value. In this case, we require this value to come from the CLI (get_param) (Edited per comments)
  • 12 – 15: This is where we set up a string replacement. The specifies a string in which we perform replacements. The “params” specifies what to replace with.
• 16 – 25: Image – Specifies which image to use. A lot of this follows the same setup as lines 8-15. That said, note 22 – 25. This provides constraints on inputs. In this case defining images that can be used.
• 26-39 – Flavor – Specifies the flavors to use. Note: These flavors are rather Rackspace Cloud centric. You can modify to fit your OpenStack deployment.
• 41 – 65: Resources – Resources is a required section. It specifies what resources will be deployed and how they will be configured when you launch the Heat template. There are a number of resource types available, a relatively complete list can be found here: http://docs.openstack.org/developer/heat/template_guide/openstack.html
  • 42 – 65: “spiderfoot” This specifies the one resource we will be deploying as such:
    • 42: The name of the resource
    • 43: The type (complete list of types: http://docs.openstack.org/developer/heat/template_guide/openstack.html)
    • 45 – 47: Remember those parameters from earlier in the file. Here is where they get assigned to our resource.
    • 48 – 65: These are our “post install” lines. Basically, once the resource is up, these get run.

Note: Don’t actually use these, especially 48 – 65. I do some terrible things like setting the root password to vagrant and running an InfoSec service that has no auth control (basically anyone, anywhere, can use the box to scan /anything/). I’ve only provided this as an example of how to assemble a Heat template

• 66 – End of the file: These specify outputs available. These are what becomes available using the heat stack-list and heat stack-show commands.

Summary

Ok, in what turned out to be a much longer post than I’d anticipated, we built a very very simple heat template. Hope this has been helpful. In some future posts, I’ll show how to deploy Heat itself and from there, how to use this template to deploy against it.