It’s Getting HOT in here: OpenStack Orchestration with Heat

Are you feeling HOT, HOT, HOT? (Templates that is). As the OpenStack platform continues to evolve and extend, a lot of great work is happening in an area that is one of my favorites, orchestration. The OpenStack orchestration program goes by the codename Heat, and is something that I’ve got a lot of work building up around in the coming months.

Deployment and scaling of application infrastructure is one of the powerful features within a cloud environment. By using Heat as a stack orchestration product, you’ll get the advantage of using OpenStack for all that it has to offer as your core infrastructure, plus the community contributed Heat templates are going to be a great way to kick your app infrastructure into high gear!

YAML all the things!

As I’ve had a long of experience managing Ruby on Rails environments, I learned about the ease of use with YAML (YAML Ain’t Markup Language) that you can find out about from the Wikipedia page (

Using the easy-to-read YAML syntax we can do a lot of different things in various DSL (Domain Specific Languages). Even in non-DSL deployments of just plain scripting, there are plugins to use YAML configuration files. I’ve been experimenting with YAML and PowerShell with good success (a long overdue blog post) to help keep configurable parameters out of the code and into simple files that admins and developers can manage.

It’s getting HOT in here

Templates are quite simple to figure out once you work through some examples. Because programming is always started with the classic “Hello World”, let’s use that as our starting point to view what a HOT template looks like.

From the Heat Example Templates Github page, I’ve picked this as our example:

Heat templates are based on creating what we call “stacks” which can be single or multiple servers with in-guest configuration and other exciting management capabilities. This stack will be a single instance as you can see.

Sections of the Heat template are defined here as Parameters, Resources, and Output.

In the parameters section we define content such as the flavor of the server we are launching, the image we will use as the boot image, admin password, SSH key, and database port. You can see that some have additional parameters by type such as admin_pass which can also have added constraints for password policies to ensure that it will meet the criteria needed. Parameters can have default values also which helps where someone may not know what the appropriate value should be.


Once our parameters are defined, we can now pull them into the resources for the template which will request information from who triggers the deployment. Each parameter will be put into the deployment of our Nova instance based on the values provided and the constraints defined in the parameters section. This is what our resources section looks like in the template:


Once our instance is deployed, we can also define what is returned back to the implementer as output. This simple template will provide the network information that is put into the instance during deployment.


This is a rudimentary example, and we can look through the full Github page for many more detailed examples:

What’s Next?

The Heat program will definitely be a spot where we should spend some time looking at how to build out the right definitions for what our OpenStack cloud consumers will be using. The name of the game here is ease-of-use and by creating well designed Heat templates, we can further enable our consumer to get the best value out of our infrastructure.

This is just a quick view of a basic template, but look for more here in the coming weeks as we extend and build out some sample HOT files together.

Happy stacking!

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.