Heat is OpenStack's orchestration service for launching multiple composite cloud applications called "stacks" using templates. It provides an API and templates to define resources and allow repeatable, automated deployments. The Heat architecture uses a central engine and plugins to provision resources across OpenStack services. New features improve reliability, scalability, and allow concurrent stack updates through a convergence engine.

1. HEAT AND ITS RESOURCES
(Orchestration for Openstack)
Presented By
Sangeethkumar
sangeethcloud@gmail.com

2. Agenda
 HEAT overview
 HEAT Architecture & Services
 HEAT Template
 How it works?
 Stack Actions
 HEAT resources
 Problems in HEAT engine
 New Features of HEAT
 Future Roadmap Features

3. HEAT Overview
 Started in March 2012
 Incubated for Grizzly, Integrated for Havana
 Orchestration engine to launch multiple composite cloud
applications called ”stack”, in a text file called “template”.
 Provides both an OpenStack-native ReST API and a
CloudFormation-compatible Query API.
 Repeatable application deployments
 High availability and Auto scaling

4. HEAT Architecture

5. Plugin Support

6. HEAT Template

7. How it works??
 Heat exposes some API that clients can use to send templates
to the Heat engine, which parse them and it will communicate
with all OpenStack services to deploy the resources and create
the stack.
 CLI : heat stack-create -f template.yaml

8. Working of HEAT from Infrastructure
level
 Requires images with cloud-init and heat-cfntools

9. How heat works from Instance side?

10. Why we need heat-cfn-tools??
 “cfn-tool” package provides all the helper scripts and daemons
that heat needs in order to work
 cfn-init: the helper script that initialize the instance at boot time,
executing userdata.
 cfn-hup: the daemon that periodically checks services status
for High Availability, sends metrics to CloudWatch and execute
hooks when events occur.
 cfn-push-stats: the helper script that send metrics to
CloudWatch service.
 cfn-signal: the helper script that sends signals to Heat API.

11. Stack actions
 heat stack-abandon
usage: heat stack-abandon <NAME or ID>
Record of the stack from Heat, but will not delete any of the underlying resources.
 heat stack-adopt
usage: heat stack-adopt [-e <FILE or URL>] [-c <TIMEOUT>] [-t <TIMEOUT>]
[-a <FILE or URL>] [-r]
[-P <KEY1=VALUE1;KEY2=VALUE2...>]
<STACK_NAME>
 heat stack-create
usage: heat stack-create [-f <FILE>] [-e <FILE or URL>]
[--pre-create <RESOURCE>] [-u <URL>] [-o <URL>]
[-c <TIMEOUT>] [-t <TIMEOUT>] [-r]
[-P <KEY1=VALUE1;KEY2=VALUE2...>] [-Pf <KEY=FILE>]
[--poll [SECONDS]] [--tags <TAG1,TAG2>]
<STACK_NAME>
Creates a Stack / Template execution
 heat stack-delete
usage: heat stack-delete <NAME or ID> [<NAME or ID> …]
Deletes the Stack and its resources

12. Stack actions
 heat stack-list
usage: heat stack-list [-s] [-n] [-a] [-f <KEY1=VALUE1;KEY2=VALUE2...>]
[-t <TAG1,TAG2...>] [--tags-any <TAG1,TAG2...>]
[--not-tags <TAG1,TAG2...>]
[--not-tags-any <TAG1,TAG2...>] [-l <LIMIT>] [-m <ID>]
[-k <KEY1,KEY2...>] [-d [asc|desc]] [-g] [-o]
List the user's stacks.
 heat stack-preview
usage: heat stack-preview [-f <FILE>] [-e <FILE or URL>] [-u <URL>] [-o <URL>]
[-t <TIMEOUT>] [-r]
[-P <KEY1=VALUE1;KEY2=VALUE2...>] [-Pf <KEY=FILE>]
[--tags <TAG1,TAG2>]
<STACK_NAME>
 heat stack-show
usage: heat stack-show <NAME or ID>
 heat stack-snapshot
usage: heat stack-snapshot [-n <NAME>] <NAME or ID>
 heat stack-restore
usage: heat stack-restore <NAME or ID> <SNAPSHOT>

13. Stack actions
 heat stack-update
usage: heat stack-update [-f <FILE>] [-e <FILE or URL>]
[-u <URL>] [-o <URL>]
[-t <TIMEOUT>] [-r] [--rollback <VALUE>] [-y]
[-P <KEY1=VALUE1;KEY2=VALUE2...>] [-Pf <KEY=FILE>]
[-x] [-c <PARAMETER>] [--tags <TAG1,TAG2>]
<NAME or ID>
 heat stack-cancel-update
usage: heat stack-cancel-update <NAME or ID>
 On resources
Show - show the details of a particular resource
Metadata - show the metadata associated with a particular resource
List - list the resources that a stack is using
 On events
List - list all the events a stack has experienced.
Show - show the details of a particular resource.

14. HEAT Resources Plugin
Integrates the OpenStack services with
heat for orchestrating their elements as
part heat stack.
Has its own namespace like Cloud
Provider :: Service :: Resource
Examples: OS::Nova::Server,
OS::Cinder::Volume
Supports following Life-cycle operations
 Create / Update / Delete
 Snapshot / restore
 Abandon / adopt

15. As Stack is processed in a single heat-engine,
irrespective of available heat-engines:
•Capacity is an bottle-neck:
when exceeds engines RAM and CPU threshold
•Reliability is compromised:
Engine fails, then stack is FAILED, but user can't recover engine failure, suppose
operators.
•Concurrent-update is not available
Once stack is locked by a heat-engine, it unlocks only after stack is provisioned.
User end-up in waiting, till stack completes.
In addition, After stack provisioning, On any
underlying cloud infra failure, causes stack as unstable
KVM is down
Network connection is interrupted
Etc.

16. New Features
 API to cancel and roll back an in-progress
stack update
 Remember the previously-supplied
parameters when updating a stack
 Software deployments can now use Zaqar
for deploying software data and signalling back
to Heat
 Stack actions are now performed on
remote OS::Heat::Stack resources

17. Convergence
 Convergence is a new orchestration engine maturing in the heat tree. In
Liberty, the benefits of using the convergence engine are:
 Greater parallelization of resource actions (for better scaling of large
templates)
 The ability to do a stack-update while there is already an update in-progress
 Better handling of heat-engine failures
 The convergence engine can be enabled by setting /etc/heat/heat/conf
[DEFAULT] convergence_engine=true, then restarting heat-engine. Once
this has been done, any subsequent created stack will use the convergence
engine, while operations on existing stacks will continue to use the traditional
engine.