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
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
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
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.