Jump to: navigation, search

Difference between revisions of "Heat"

(fixed cut and past errors)
(Meetings)
 
(79 intermediate revisions by 28 users not shown)
Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
<<[[TableOfContents]]()>>
 
  
'''Project codename''': Heat
+
= OpenStack Orchestration =
  
'''Summary''':
+
The mission of the OpenStack Orchestration program is to create a human- and machine-accessible service for managing the entire
 +
lifecycle of infrastructure and applications within OpenStack clouds.
  
[http://www.heat-api.org Heat] provides a REST API to orchestrate multiple composite cloud applications implementing the [http://docs.amazonwebservices.com/AWSCloudFormation/latest/APIReference/Welcome.html?r=7078 AWS CloudFormation] API.
+
= Heat =
 
 
'''Detailed Description''':
 
 
 
What is the purpose of the project and vision for it?
 
 
 
* The vision of Heat is to provide an AWS [[CloudFormation]] implementation for [[OpenStack]] that converts an AWS [[CloudFormation]] template describing a cloud application and executes appropriate API calls using [[OpenStack]] APIs to generate a running cloud application. 
 
 
 
Describe the relevance of the project to other [[OpenStack]] projects and the [[OpenStack]] mission to provide a ubiquitous cloud computing platform:
 
 
 
* The software provides support for most resource types defined by [[CloudFormation]].  The developers have added high availability by monitoring applications and virtual machines.  We are close to adding autoscaling technology to allow one type of instance to be reused one or more times to scale out a cloud application.  We also have recently added nested stacks which allow one stack to be used as a resource type for a parent stack in a template-friendly way.
 
* Currently no other [[CloudFormation]] implementation exists for [[OpenStack]].  The developers believe cloud developers have a strong desire to move workloads from AWS to [[OpenStack]] deployments.  Given the missing gap of a well-implemented and integrated [[CloudFormation]] API in [[OpenStack]], we provide a high quality implementation of this gap.
 
 
 
'''Basic roadmap for the project''':
 
 
 
Targeted at Folsom:
 
* Complete integration with Common, Glance, Keystone, Swift, and Nova
 
* Complete implementation of the AWS [[CloudFormation]] API
 
* Usable implementation of AWS [[CloudWatch]] API
 
* Complete implementation for all non-VPC related resource types in [[CloudFormations]]
 
* Instance and application high availability
 
* Autoscaling
 
* Nested Stacks
 
 
 
Targeted at G release:
 
* incubation
 
* Optimizing project governance to match [[OpenStack]] standards
 
* Complete implementation of AWS [[CloudWatch]] API, contributing appropriate technology into Ceilometer
 
* Complete integration with Quantum, providing complete VPC feature coverage
 
 
 
Targeted at H release:
 
* Hardening of source tree
 
* Improving source tree to meet [[OpenStack]] design principles
 
* Promotion to core
 
 
 
'''Location of project source code''':
 
* [[GitHub]] Repository: https://github.com/heat-api
 
* Web Site: http://www.heat-api.org
 
 
 
'''Programming language, required technology dependencies''':
 
* Python2, matching [[OpenStack]] design principles
 
 
 
All dependencies are standard [[OpenStack]] technology dependencies:
 
* python-crypto
 
* python-eventlet
 
* python-glance
 
* pyton-greenlet
 
* python-httplib2
 
* python-iso8601
 
* python-keystoneclient
 
* python-kombu
 
* python-lxml
 
* python-memcached
 
* python-migrate
 
* python-novaclient
 
* python-paste
 
* python-routes
 
* pysendfile
 
* python-sqlalchemy
 
* python-webob
 
 
 
'''Is project currently open sourced? What license?''':
 
ASL 2.0 - Open since project inception in March 2012
 
 
 
'''Level of maturity of software and team''':
 
* software - medium - for example we are missing VPC functionality
 
* team - high
 
  
'''Proposed project technical lead and qualifications''':
+
Heat is the main project in the OpenStack Orchestration program. It implements an orchestration engine to launch multiple composite cloud applications based on templates in the form of text files that can be treated like code. A native Heat template format is evolving, but Heat also endeavours to provide compatibility with the [http://docs.amazonwebservices.com/AWSCloudFormation/latest/APIReference/Welcome.html?r=7078 AWS CloudFormation] template format, so that many existing CloudFormation templates can be launched on OpenStack. Heat provides both an [http://developer.openstack.org/api-ref-orchestration-v1.html OpenStack-native ReST API] and a CloudFormation-compatible Query API.
Our proposed PTL is:
 
* Steven Dake - 10 years distributed computing experience - 15 years software development experience, Led development of the Corosync Cluster Engine (http://www.corosync.org). A leader in driving the Linux high availability development and user community to adopt a common set of building blocks and technologies to support high availability on Linux platforms.
 
  
An alternate strong PTL candidate is:
+
Why ‘Heat’? It makes the clouds rise!
* Angus Salkeld - 5 years clustering, 8 1/2 years embededed linux - 11 years software development experience.  A leader in driving the Linux high availability development community to adopt libqb (https://github.com/asalkeld/libqb) used as a standard infrastructure library.
 
  
'''Other project developers and qualifications''':
+
== How it works ==
* Chris Alfonso - 13 years of professional software development and system administration experience, specializing in open source computing. Led development of hosted x.509 based subscription management platform (http://access.redhat.com/management) and contributed to many open source projects.
 
* Zane Bitter - 8 years professional software development experience, specialising in embedded systems, mostly Linux, including 4 years developing Ethernet L3 switches.
 
* Greg Blomquist - 12 years of software development experience with a focus on web application development and administration.
 
* Steven Hardy - 12 years software development experience, distributed application development, device drivers and enterprise systems management. Spacewalk (www.spacewalk.redhat.com) & Linux kernel contributor.
 
* Ian Main - 5 years of distributed computing expierence - 14 years of professional software development.  Lots of open source work including GTK+, GNOME, and many other projects.
 
* Jeff Peeler - 4.5 years software development experience. Worked on Asterisk (www.asterisk.org) for 3 years while employed by Digium.
 
* Tomas Sedovic - 4 years software development experience, worked on the Aeolus (http://aeolusproject.org/) project.
 
  
'''Infrastructure requirements (testing, etc)''':
+
* A Heat template describes the infrastructure for a cloud application in a text file that is readable and writable by humans, and can be checked into version control, diffed, &c.
We have integrated with stackforge, which recently moved into [[OpenStack]]'s infrastructure. We use the [[OpenStack]] workflow including gerrit/jenkins.
+
* Infrastructure resources that can be described include: servers, floating ips, volumes, security groups, users, etc.
 
+
* Heat also provides an autoscaling service that integrates with [[Telemetry]], so you can include a scaling group as a resource in a template.
'''Have all current contributors agreed to the OpenStack CLA?'''
+
* Templates can also specify the relationships between resources (e.g. this volume is connected to this server). This enables Heat to call out to the OpenStack APIs to create all of your infrastructure in the correct order to completely launch your application.
Yes
+
* 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 knows how to make the necessary changes. It will delete all of the resources when you are finished with the application, too.
 
+
* Heat primarily manages infrastructure, but the templates integrate well with software configuration management tools such as [https://s3.amazonaws.com/cloudformation-examples/IntegratingAWSCloudFormationWithPuppet.pdf Puppet] and [http://www.full360.com/2011/02/27/integrating-aws-cloudformation-and-chef.html Chef]. The Heat team is working on providing even better integration between infrastructure and software.
'''Status''': To be completed by PPB
 
 
 
= Archive =
 
 
 
= Heat =
 
 
 
[http://www.heat-api.org Heat] provides a REST API to orchestrate multiple composite cloud applications implementing the [http://docs.amazonwebservices.com/AWSCloudFormation/latest/APIReference/Welcome.html?r=7078 AWS CloudFormation] API.
 
 
 
Why heat?  It makes the clouds rise!
 
  
 
== Architecture ==
 
== Architecture ==
  
The developers are focused on creating an [[OpenStack]] style project using [[OpenStack]] design tenants implemented in Python.  We have started with full integration with Keystone.  We have three components.
+
Heat comprises a number of Python applications:
 
 
An [http://heat-api.org/architecture.html overview] of the architecture is available.  As the developers have only started development in March 2012, the architecture is evolving rapidly.
 
  
 
=== heat ===
 
=== heat ===
  
The heat tool is a CLI which communicates with the heat-api to execute AWS [[CloudFormation]] APIs. End developers could also use the heat REST API directly.
+
The heat tool is a CLI which communicates with the heat-api to execute AWS CloudFormation APIs. Of course this is not required—developers could also use the Heat APIs directly.
  
 
=== heat-api ===
 
=== heat-api ===
  
The heat-api component provides a REST API that processes API requests by sending them to the heat-engine.
+
The heat-api component provides an [http://developer.openstack.org/api-ref-orchestration-v1.html OpenStack-native ReST API] that processes API requests by sending them to the heat-engine over RPC.
  
=== heat-engine ===
+
=== heat-api-cfn ===
  
The heat engine connects to the heat-api over RPC to process API operations.  The heat engine's main responsibility is to orchestrate the launching of templates and provide events back to the API consumer.
+
The heat-api-cfn component provides an AWS-style Query API that is compatible with AWS CloudFormation and processes API requests by sending them to the heat-engine over RPC.
  
The templates integrate well with [https://s3.amazonaws.com/cloudformation-examples/IntegratingAWSCloudFormationWithPuppet.pdf Puppet] and [http://www.full360.com/blogs/integrating-aws-cloudformation-and-chef Chef]
+
=== heat-engine ===
 
 
= Getting Started Guides =
 
Getting started on Fedora 16 & 17 https://github.com/heat-api/heat/blob/master/docs/GettingStarted.rst
 
 
 
Getting started on Ubuntu Precise https://github.com/heat-api/heat/wiki/Getting-Started-with-Heat-using-Master-on-Ubuntu.
 
 
 
= Links =
 
 
 
[[GitHub]] Repository: https://github.com/heat-api
 
 
 
Wiki Documentation: https://github.com/heat-api/heat/wiki
 
 
 
Web Site: http://www.heat-api.org
 
  
Mailing List: [http://lists.heat-api.org/mailman/listinfo here]
+
The heat engine does the main work of orchestrating the launch of templates and providing events back to the API consumer.
  
Milestones: [https://github.com/heat-api/heat/issues/milestones here]
+
== Development ==
 +
* [https://github.com/openstack/heat Source repository]
 +
* [https://github.com/openstack/python-heatclient Client source repository]
 +
* [https://github.com/openstack/heat-templates Example templates]
 +
* [https://storyboard.openstack.org/#!/project_group/82 Bug/Feature tracker]
 +
* [http://tarballs.openstack.org/heat/ Tarballs]
 +
* [[Heat/Plugins|Heat Plugin Developer Guide]]
 +
* [[Heat/DevelopmentProcess|Developer Process]]
 +
* [[Heat/CoreTeam|Core Team]]
 +
* [https://review.openstack.org/#/dashboard/?foreach=%2528project%253Aopenstack%252Fheat+OR+project%253Aopenstack%252Fheat%252Dagents+OR%250Aproject%253Aopenstack%252Fheat%252Dtemplates+OR+project%253Aopenstack%252Fpython%252Dheatclient+OR%250Aproject%253Aopenstack%252Fheat%252Dcfntools+OR+project%253Aopenstack%252Fheat%252Dspecs+OR%250Aproject%253Aopenstack%252Fheat%252Ddashboard+OR+project%253Aopenstack%252Fheat%252Dtempest%252Dplugin%2529%250Astatus%253Aopen+NOT+owner%253Aself+NOT+label%253AWorkflow%253C%253D%252D1+label%253AVerified%253E%253D1%250ANOT+label%253ACode%252DReview%253C%253D%252D1%252Cself+NOT+label%253ACode%252DReview%253E%253D1%252Cself&title=Heat+Review+Inbox&Heat+Specs=project%253Aopenstack%252Fheat%252Dspecs&Stories+and+Bugs+Fixes=%2528intopic%253A+%255Estory%252F.%252A+OR+intopic%253A+%255Ebug%252F.%252A%2529&Blueprints=message%253A%2522Blueprint%2522&Needs+Feedback+%2528Changes+older+than+5+days+that+have+not+been+reviewed+by+anyone%2529=NOT+label%253ACode%252DReview%253E%253D1+NOT+label%253ACode%252DReview%253C%253D%252D1+age%253A5d&You+are+a+reviewer%252C+but+haven%2527t+voted+in+the+current+revision=reviewer%253Aself&Needs+final+%252B2=label%253ACode%252DReview%253E%253D2+limit%253A50&New+Contributors=reviewer%253A10068&Passed+Zuul%252C+No+Negative+Feedback=NOT+label%253ACode%252DReview%253E%253D2+NOT+label%253ACode%252DReview%253C%253D%252D1+limit%253A50 Code Review Dashboard]
  
Open Issues: [https://github.com/heat-api/heat/issues?sort=created&direction=desc&state=open here]
+
== Getting Started Guides ==
 +
There are getting started guides for several distributions in the [http://docs.openstack.org/developer/heat/getting_started/index.html Heat Documentation]
 +
* The installation guides on http://docs.openstack.org
 +
* [http://docs.openstack.org/developer/heat/getting_started/on_fedora.html Getting Started With Heat on Fedora]
 +
* [http://docs.openstack.org/developer/heat/getting_started/on_ubuntu.html Getting Started With Heat on Ubuntu]
 +
* [http://docs.openstack.org/developer/heat/getting_started/on_devstack.html Heat and Devstack]
 +
* [http://docs.openstack.org/user-guide/content/heat_client_commands.html Heat chapter] of the [http://docs.openstack.org/cli/quick-start/content/index.html OpenStack Clients Guide]
  
= IRC =
+
== Other Links ==
 +
* [http://docs.openstack.org/developer/heat/template_guide/hot_guide.html Heat Orchestration Template (HOT) Guide]
 +
* [[Heat/ApplicationDeployment|How Heat uses CloudFormation and cloud-init for application deployment]]
 +
* [[Heat/BotoCompatibility|Boto Compatibility Matrix]]
 +
* [[Heat/VPC Resources Support|VPC Resources Support]]
 +
* [https://wiki.openstack.org/w/index.php?title=Special%3APrefixIndex&prefix=Heat&namespace=0 All topics in the Heat Wiki Namespace]
 +
* [https://wiki.openstack.org/wiki/Heat-Translator Heat Translator Project]
  
The developers use IRC on #heat on freenode for development discussion.
+
== [https://review.openstack.org/#/admin/groups/114,members heat-core] Blogs & Presentation Material ==
 +
* Steve Baker [http://blog.stevebaker.org/ Blog]
 +
* Zane Bitter [http://www.zerobanana.com/tags/OpenStack Blog] & [https://github.com/zaneb/presentations/releases Presentation Material]
 +
* Steve Dake [https://sdake.wordpress.com/ Blog] & [https://github.com/sdake/slides Presentation Material]
 +
* Steve Hardy [https://hardysteven.blogspot.co.uk/ Blog] & [https://github.com/hardys/presentations Presentation Material]
 +
* Angus Salkeld [http://ahsalkeld.wordpress.com/ Blog]
  
= Status of implementation =
+
= Get involved =
 +
== IRC ==
  
March 16, 2012 - Code base started.
+
The developers use IRC in <code>#heat</code> on [https://www.oftc.net/ OFTC] for development discussion.
  
April 4, 2012 - Launching a [[WordPress]] template with [https://github.com/heat-api/heat/tarball/v1-POC.release POC].  See Heat's [https://github.com/heat-api/heat/wiki/HeatGettingStartedPOC getting started guide]. 
+
== Meetings ==
  
April 23, 2012 - Multiple Instance [[WordPress]] template [https://github.com/heat-api/heat/tarball/v2-M1.release v2-M1]. See Heat's [https://github.com/heat-api/heat/wiki/Getting-Started-with-Heat-v2-M1 getting started guide].
+
Meetings are held on IRC in <code>#heat</code> on [https://www.oftc.net/ OFTC] every Wednesday. See the [http://wiki.openstack.org/Meetings/HeatAgenda Heat agenda page] for times and details.
  
May 14, 2012 - High Availability [https://github.com/heat-api/heat/tarball/v3.release v3].  See Heat's [https://github.com/heat-api/heat/wiki/Getting-Started-with-Heat-v3 getting started guide].
+
== Mailing list ==
  
June 27, 2012 - Ubuntu Support, High Availability improvements, more templates [https://github.com/heat-api/heat/tarball/v4.release v4]. See Heat's [https://github.com/heat-api/heat/wiki wiki] for documentation to get started.
+
Discussions about Heat happens on the [http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev openstack-dev] mailing list. Please use the tag <code>[Heat]</code> in the subject line for new threads.
----
 
[[Category:RelatedProjects]]
 

Latest revision as of 10:19, 30 March 2023


OpenStack Orchestration

The mission of the OpenStack Orchestration program is to create a human- and machine-accessible service for managing the entire lifecycle of infrastructure and applications within OpenStack clouds.

Heat

Heat is the main project in the OpenStack Orchestration program. It implements an orchestration engine to launch multiple composite cloud applications based on templates in the form of text files that can be treated like code. A native Heat template format is evolving, but Heat also endeavours to provide compatibility with the AWS CloudFormation template format, so that many existing CloudFormation templates can be launched on OpenStack. Heat provides both an OpenStack-native ReST API and a CloudFormation-compatible Query API.

Why ‘Heat’? It makes the clouds rise!

How it works

  • A Heat template describes the infrastructure for a cloud application in a text file that is readable and writable by humans, and can be checked into version control, diffed, &c.
  • Infrastructure resources that can be described include: servers, floating ips, volumes, security groups, users, etc.
  • Heat also provides an autoscaling service that integrates with Telemetry, so you can include a scaling group as a resource in a template.
  • Templates can also specify the relationships between resources (e.g. this volume is connected to this server). This enables Heat to call out to the OpenStack APIs to create all of your infrastructure in the correct order to completely launch your application.
  • 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 knows how to make the necessary changes. It will delete all of the resources when you are finished with the application, too.
  • Heat primarily manages infrastructure, but the templates integrate well with software configuration management tools such as Puppet and Chef. The Heat team is working on providing even better integration between infrastructure and software.

Architecture

Heat comprises a number of Python applications:

heat

The heat tool is a CLI which communicates with the heat-api to execute AWS CloudFormation APIs. Of course this is not required—developers could also use the Heat APIs directly.

heat-api

The heat-api component provides an OpenStack-native ReST API that processes API requests by sending them to the heat-engine over RPC.

heat-api-cfn

The heat-api-cfn component provides an AWS-style Query API that is compatible with AWS CloudFormation and processes API requests by sending them to the heat-engine over RPC.

heat-engine

The heat engine does the main work of orchestrating the launch of templates and providing events back to the API consumer.

Development

Getting Started Guides

There are getting started guides for several distributions in the Heat Documentation

Other Links

heat-core Blogs & Presentation Material

Get involved

IRC

The developers use IRC in #heat on OFTC for development discussion.

Meetings

Meetings are held on IRC in #heat on OFTC every Wednesday. See the Heat agenda page for times and details.

Mailing list

Discussions about Heat happens on the openstack-dev mailing list. Please use the tag [Heat] in the subject line for new threads.