Module 10

Heat-
OpenStack Orchestration
Module 10 Objectives
By the end of this lecture module, you should be able to explain for Heat:
•  Purpose, function and architecture
•  Functional integration with other OpenStack projects and in particular the
integration of alarm notification with Telemetry
•  The structure and function of a Heat Orchestration Template
•  How Heat enables autoscaling functionality in OpenStack
OpenStack Orchestration (Heat)
Network  
Block   Neutron   Image  
Storage   Store  
Glance  
Cinder   OpenStack  
Object      Core   AuthX  
Storage   Keystone  
Swi7   Compute   Orchestra)on  
Nova   Heat  

What is it? What can it do?

•  Template-based automation for •  Deploy Compute, Network, Storage,
OpenStack services Images, etc.
•  The “next” level of automation •  Pass application deployment logic to
instances
•  Monitor deployed VMs and add
capacity to a load balancer
Heat - Horizon
 Heat - Things you can do with the CLI
Here are some of the basic things you may want to do with Heat and examples with the Heat and
OpenStack CLI commands.

●  Manage stacks

●  Manage resources

Example : Heat CLI- heat stack create - create a Heat stack

$ heat stack-create -f first-stack.yml

Heat - Things you can do with the CLI
 Heat - Things you can do with the CLI
# heat_template_version: 2013-05-23 router1:
description: HOT template for two interconnected VMs. type: OS::Neutron::Router
parameters: properties:
image_id: external_gateway_info:
type: string network: { get_param: public_net }
description: Image Name
secgroup_id: router1_interface:
type: string type: OS::Neutron::RouterInterface
description : Id of the security groupe properties:
public_net: router_id: { get_resource: router1 }
type: string subnet_id: { get_resource: private_subnet }
description: public network id
resources: server1_port:
private_net: type: OS::Neutron::Port
type: OS::Neutron::Net properties:
properties: network_id: { get_resource: private_net }
name: private-net security_groups: [ get_param: secgroup_id ]
private_subnet: fixed_ips:
type: OS::Neutron::Subnet - subnet_id: { get_resource:
private_subnet }
properties:
network_id: { get_resource: private_net }
………}
cidr: 172.16.2.0/24
gateway_ip: 172.16.2.1
Heat- Cloud Application Templates
•  OpenStack Heat Orchestration Templates (HOT)
•  Template based orchestration for describing a cloud
application by executing appropriate OpenStack API
calls to generate running cloud applications <…>
Allows creation of most OpenStack resource types
(such as instances, floating ips, volumes, security
groups, users, etc)
•  Templates can be provided by Partner, and/or
uploaded by the end tenant

8
Heat (OpenStack Orchestration)
•  Repeatable, fully automated orchestration of deployments within OpenStack

•  Integrates with all OpenStack core projects

•  Converts a YAML HOT template into a cloud application

•  Implements templates through OpenStack native REST API

How Heat Works
•  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 primarily manages infrastructure, but the templates integrate

well with software configuration management tools such as Puppet
and Chef.
How Heat Works
•  A Heat template describes the infrastructure for a cloud application in a text
file that is readable and writable by humans.

•  Infrastructure resources that can be described include:

•  Servers
•  Floating IPs
•  Volumes
•  Security Groups
•  Users, etc.

•  Heat also provides an auto scaling service that integrates with Ceilometer.
•  Templates can also specify the relationships between resources.
Example Heat Orchestration Template
heat_template_version: 2013-05-23
server1_port:
type: OS::Neutron::Port
description: Test Template
properties:
network: { get_param: NetName }

parameters:
ImageName:
type: string outputs:
description: Image use to boot a server server1_private_ip:
NetName: description: IP address of the server in the
type: string private network
description: Network ID for the server value: { get_attr: [ server1, first_address ] }

resources:
server1:
type: OS::Nova::Server
properties:
name: "Test server"
image: { get_param: ImageName }
flavor: "m1.tiny"
networks:
- port: { get_resource: server1_port }
Heat Orchestration Flow
Input: Template

Input: URL or
Parameters Template File /
Parameter Data

Heat CLI Outputs

REST

Heat REST API

AMQP

Heat Engine
Heat Autoscaling
•  Provides an auto scaling service that integrates with Ceilometer.

•  Metrics or user events drive scaling

•  Dynamically add and reduce OS::Nova::Server resources to meet demand

•  Front end Neutron LBaaS or Heat provided HA-Proxy Load Balancer

distributes load to server resources
Heat Autoscaling - Workflow
•  User instantiates HOT with Heat's CLI

•  Heat registers with Ceilometer for callbacks on Alarm events

•  Ceilometer tells Heat about Alarm events and Heat scales a Group based on
a Policy decision to scale up or down

Example:
https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml
(includes a sub-template too!):
https://github.com/openstack/heat-templates/blob/master/hot/lb_server.yaml
Heat Review

•  Why are OpenStack users so excited about HOT?

•  What does HOT stand for?
•  Which OpenStack service must Heat interact with to have system
‘awareness?’
•  What language is a HOT written in?
•  …
Heat - Further Reading
Explanation of commands and additional optional arguments are available at:
http://docs.openstack.org/cli-reference/content/heatclient_commands.html

Administration Guide:
http://docs.openstack.org/admin-guide-cloud/content/ch_admin-openstack-
orchestration.html