OpenStack Heat Orchestration - Let’s build a whole neighborhood!

If you wanted to build a house, a block, or a neighborhood, you’d start with a blueprint. Some authoritative document that you rely on to determine how each component should look and operate to turn your vision into a bustling neighborhood with houses, cafes, pizzerias, schools, and businesses. The complexity of working with OpenStack Orchestration (Heat) templates often keeps people away from them. In this multipart series on Heat Orchestration templates (also known as “Heat Stacks”), we’re going to peel the onion one layer at a time and demystify some of the capabilities of using Heat Stacks. We will create blueprints for those houses, blocks and neighborhoods, and then we’ll build them. If you are already familiar with Red Hat OpenStack Platform, have an operating OpenStack environment of any size, and are generally familiar with how it works, this is for you.  

Let’s feel the heat:

Simply put, Heat Orchestration templates are architectural visions or plans for building a house, a block, or an entire neighborhood. The yaml formatted text document used for defining this is called a Heat template.  

Heat templates can define as little, or as much as you wish them to. They are a blank canvas upon which you will draft the plans. It’s important to note that it’s up to you to define the scale and complexity. A Heat template can define a single server that joins an existing OpenStack Networking (Neutron), or it can define hundreds of them, each with encrypted cinder volumes, connected to distinct networks and routers, and invoke features of OpenStack APIs such as LBaaSv2 or FWaaS. It can also manage the lifecycle of these entities, and modify or destroy them as a set.

Taking a look at a Heat template:   

  -- It’s always better to approach a porcupine from the front.

A Heat template has three basic sections:

• Version - Defined as heat_template_version, this looks very much like a date, because it is. As the Heat specification matured, newer versions were cut that contain more and more functionality. If you attempt to use a feature that didn’t exist in that version, the orchestration engine will bark about it and send you back to the drawing board.

• Parameters - This is an area for variables that you want to define. Our template has two: key_name is a definition of what ssh key to build the server with, and network_name is which neutron network to put the server on.   

• Resources - The resources section defines the objects or assets to be created. Here you define the type of object (OS::Nova::Server) and at least the minimum required pieces of information to build it. The Heat specification can tell you what is required or available. There are many different resource types available. Check out the full list of resource types.

• In our example, we are specifying the minimum for flavor, image, and network. We went beyond that and included an ssh key, which we defined as a parameter. It is called by the parameter name here:

           key_name: {get_param: key_name}

That’s a basic template. Now let’s run it and observe the result:

[root@osp11 heat(p)]# openstack stack create -t single_server.yaml SINGLE_SERVER

You’ll see the server appear inside the assigned network, after which we will open up a console and show it booting. This animated gif is how it looks in real time.

In summary, a Heat template is a document that acts as a blueprint for creating what is called a stack in the parlance of OpenStack. A stack can contain and use any entity type that can live in OpenStack, including servers, networks, subnets, routers, LBaaSv2 components and even single network interfaces. Heat is even used by Red Hat OpenStack Platform director to deploy the overcloud.

This demonstration teased out a simple example of a Heat template, and in the next example, I will demonstrate a more realistic use case. As a TAM, I often have to reproduce my customer’s issues to analyze technical problems or prove solutions for them. This can require a huge variety of Red Hat Enterprise Linux instances, all at different versions and configurations. Let’s take a look at how I use a single Heat template to spin up an entire ecosystem of reproducers off a single heat template and be ready to work in a short period of time. You’ll see several versions of Red Hat Enterprise Linux, Fedora, and even a Windows Server materialize.

At 365 lines, this Heat template is much more robust, and exercises a lot of extended functionality such as assigning floating IP addresses and including user data to configure each server as my use cases demand. However, it still exercises the same fundamental concepts. Actually, it exercises a lot of them.  

Imagine the benefits of your application deploying this way instead of being handcrafted in the “old world style” each and every deployment. The overarching principle of Heat is that it is definable the first time, and repeatable as many times as you want. See the full template for this example here.

Please join me on our next adventure, which will exercise more advanced components of Red Hat OpenStack Platform through Heat templates.   

Freddy Wissing is a senior Cloud and Platform Technical Account Manager (TAM) in the Northeast region. He has expertise in Red Hat Enterprise Linux and OpenStack. Find more posts by Freddy at https://www.redhat.com/en/blog/authors/freddy-wissing 

A Red Hat TAM is a specialized product expert who works collaboratively with IT organizations to strategically plan for successful deployments and help realize optimal performance and growth. The TAM is part of Red Hat’s world-class Customer Experience and Engagement organization and provides proactive advice and guidance to help you identify and address potential problems before they occur. Should a problem arise, your TAM will own the issue and engage the best resources to resolve it as quickly as possible with minimal disruption to your business.

Connect with TAMs at a Red Hat Convergence event near you! Red Hat Convergence is a free, invitation-only event offering technical users an opportunity to deepen their Red Hat product knowledge and discover new ways to apply open source technology to meet their business goals. These events travel to cities around the world to provide you with a convenient, local one-day experience to learn and connect with Red Hat experts and industry peers.