OpenStack Orchestration with HeatZane Bitter24 October 2013

Contents

What is Heat?

Heat Templates

Autoscaling

Providers & Environments

Future Developments

More Information

An introduction to the OpenStack Orchestration project, Heat, andan explanation of how orchestration can help simplify the deploy-ment and management of your cloud application by allowing you torepresent infrastructure as code. Some of the major new features inHavana are also covered, along with a preview of development plansfor Icehouse.

What is Heat?

Orchestration is for infrastructure essentially what configurationmanagement is for software applications. Instead of manipulatingelements of your (virtual) infrastructure by hand, or with scripts,Heat allows you to work with a declarative model that represents theinfrastructure resources and the relationships between them directly.Heat itself then works out the correct sequence of actions to performto bring reality in line with your model.

The model takes the form of a Heat template, and the resultingcollection of infrastructure resources is known as a stack. Orchestra-tion enables you to treat your infrastructure like code—you can storethe template in a version control system to track changes to it. Whenyou do make changes, just update the stack with the new templateand Heat performs the necessary actions.

The main interface to Heat is an OpenStack-native Rest API. Asshown in Figure 1, Heat sits between the user and the APIs of thecore OpenStack services in much the same way that the Dashboard(Horizon) does. If you prefer, you can also interact with Heat throughthe Dashboard.

Identity

Keystone

Compute

Nova

Block

Storage

Cinder

Image

Glance

Object

Storage

Swift

Network

Neutron

Database

Trove

OrchestrationHeat

DashboardHorizon

Figure 1: OpenStack architecture froma user’s perspective, showing howOrchestration interacts with otherservices.

openstack orchestration with heat 2

Increasingly, Heat resource types are native representations ofthe underlying OpenStack Rest APIs, so you can access the fullpower and flexibility of OpenStack. However Heat also providesa fair degree of compatibility with CloudFormation, its functionalequivalent in Amazon Web Services.1 If you have workloads running 1 In fact, launching CloudFormation

templates on OpenStack was the initialgoal of the project.

on AWS that are defined with CloudFormation templates, it may bepossible to move them to OpenStack with few or no changes in manycases. Heat even has a CloudFormation compatibility API.2 2 In much the same way as the Open-

Stack Compute service provides an EC2

compatibility API.

Heat Templates

Parameters:ssh_key_name:

Type: StringDescription: ssh keypair name

image_name:Type: StringDescription: The image to boot

Resources:my_server:

Type: OS::Nova::ServerProperties:

flavor: m1.smallkey_name: {"Ref": "ssh_key"}block_device_mapping:

device_name: vdavolume_id: {"Ref": "my_vol"}

my_vol:Type: OS::Cinder::VolumeProperties:

size: 20image: {"Ref": "image_name"}

Outputs:server_ip:

Description: The server IPValue: {"Fn::GetAtt":

["my_server","first_address"]}

Figure 2: A simple example templatethat creates a Nova server and anattached Cinder volume. The user canspecify the image to boot from and thename of the ssh public key to installon the server, and the IP address of theserver is available as an output.

Heat templates usually take the form of simple Yaml documents.We chose this over Json, which CloudFormation uses, because it ismuch easier for humans to read and write—and a diff between twoversions of a Yaml template is usually trivial to interpret. Yaml isa strict superset of Json though, so Json is still fully supported andtemplates can be converted between the two formats with no loss offidelity.

Other than the serialisation format, Heat (for now) adheres closelyto the CloudFormation template model. (An example template isshown in Figure 2 at right.) A template has four key elements:

• An optional Parameters section, which allows user-definableinputs to be specified.

• An optional Mappings section, which allows key/value lookup ofpredefined constants.

• A mandatory Resources section, which describes the resourcesand relationships which define the application, configuration andinfrastructure.

• An optional Outputs section, which describes the output values tobe returned to the user.

All resources have a common interface:

• A number of optional or mandatory Properties which specifyinputs that affect how the resource is configured.

• A number of output attributes, which may be referenced else-where in the template using the Fn::GetAtt function.

One of the resource types available is a Heat stack, so multipletemplates can be composed into hierarchical structures.

A resource may reference any other resource or its attributes,which causes Heat to infer an ordering dependency between them.

openstack orchestration with heat 3

The template may also specify explicit dependencies where neces-sary. Lifecycle operations3 occur in parallel to the maximum extent 3 That is to say, operations such as

creating, deleting or updating a stack.possible given the dependencies between resources.A number of functions are available which allow some limited

manipulation of data within the template, for example to combineparameter data with static data in the template.

Autoscaling

Heat also provides an autoscaling service for groups of virtualservers. Currently, this is accessible only by creating a Heat templatecontaining the relevant resources (there is no separate Rest API).

ScalingGroup

LoadBalancer

LaunchConfig

Policy

Alarm

Figure 3: The reference relationships be-tween resources used to automaticallyscale a group of servers.

The resources involved are shown in Figure 3: a launch configu-ration (for new servers being added to the group), a scaling group,OpenStack Metering (Ceilometer) alarms, and scaling policies. Scal-ing groups can also update a load balancer configuration when theirmembership changes. Ceilometer alarms call a webhook—typicallythe one provided by the scaling policy resource in Heat—under de-fined circumstances, and a scaling policy will make adjustments to ascaling group based on this input and its own configuration.

Providers & Environments

Heat has added features in the Havana release aimed at making tem-plates more portable throughout the diverse OpenStack ecosystem.

The Providers feature allows users to effectively define their ownresource types. This helps mitigate the issue that users are at themercy of their cloud providers for native (Python) resource typeplugins. Provider resources are simply constructed out of nativeresources and are expressed using the exact same template syntax asstacks.4 4 In fact, they are implemented inter-

nally as stacks.Heat has also added environments, to make providers easier toconsume. An environment allows the user to override parts of thetemplate—for example, by specifying a provider template to imple-ment a particular resource type. In the ideal scenario, an organisationcould keep both a library of templates (one per application) and anorthogonal library of environments (one per cloud).5 By selecting 5 This is not a particularly realistic

scenario. In practice, environment filesare likely to be tailored to templates inmany cases.

the appropriate template and environment, any application could belaunched on any cloud without modification.

For example, you may be deploying your application to an Open-Stack cloud that features a DBaaS (and the appropriate Heat pluginfor it), but testing on a local OpenStack installation with just thebasics. You could define an environment for your test cloud thatspecifies that the DBaaS resource is supplied by a provider template

openstack orchestration with heat 4

Com

pu

te

Blo

ckS

tora

ge

Ob

ject

Sto

rag

e

Netw

ork

Data

base

Heat

Pu

pp

et,

Ch

ef

&c.

Juju

Infrastructure(Orchestration)

Software

(Configuration

Management)

...

Figure 4: The relative positioning ofHeat compared with other categoriesof software: configuration managementsystems (such as Puppet or Chef) andconfiguration managment–orchestrationhybrids (such as Juju).

containing a Nova server running MySQL. That allows you to testyour application on your local cloud without DBaaS and still deploythe self same template to staging or production.

Providers are a powerful abstraction, and it is likely we will seemore advanced uses of them in the future. You can override a na-tive resource type plugin with a provider template. That means youcould, for example, create a provider template for a server resourcethat is specialised for a particular configuration management systemor PaaS. Thus, in the main template you would only need to supplyconfiguration data for your configuration management tool ratherthan configure the tool itself on every server.

Future Developments

The Heat Orchestration Template (or Hot) format is an effort to de-velop a native template language for Heat.6 A number of cosmetic 6 Note that support for the Cloud-

Formation template format will bemaintained indefinitely.

changes have been prototyped already, with the aim of taking advan-tage of a Yaml-native format to improve the readability of templates.

Work on Hot will continue in the upcoming Icehouse develop-ment cycle to close the gap (illustrated in Figure 4) between orches-tration and configuration managment, which are complementarytechnologies.7 Likely changes involve handling dependencies and 7 The Heat team is working very hard

to avoid any overlap with configura-tion management, or reliance on anyparticular tool.

passing data between software components installed on the virtualservers that Heat configures. This will enable Heat to handle farmore complex application topologies than are currently feasible.

Development is also planned on a separate Autoscaling API, toallow access to autoscaling for users who are not using Heat tem-plates. We expect it to gain many more capabilities in the process,such as rolling updates and the ability to scale whole templates.

More Information

• ‘Heat’ page on the OpenStack Wiki

• Getting Started guides

• RDO Documentation

• Ask OpenStack

• @zerobanana

• zerobanana.com