Heat
<<TableOfContents()>> Project codename: Heat
Summary:
Heat provides a REST API to orchestrate multiple composite cloud applications implementing the AWS CloudFormation API.
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: 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:
- 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:
- 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): We have integrated with stackforge, which recently moved into OpenStack's infrastructure. We use the OpenStack workflow including gerrit/jenkins.
Have all current contributors agreed to the OpenStack CLA? Yes
Status: To be completed by PPB
Archive
Heat
Heat provides a REST API to orchestrate multiple composite cloud applications implementing the AWS CloudFormation API.
Why heat? It makes the clouds rise!
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.
An overview of the architecture is available. As the developers have only started development in March 2012, the architecture is evolving rapidly.
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.
heat-api
The heat-api component provides a REST API that processes API requests by sending them to the heat-engine.
heat-engine
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 templates integrate well with Puppet and Chef
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: here
Milestones: here
Open Issues: here
IRC
The developers use IRC on #heat on freenode for development discussion.
Status of implementation
March 16, 2012 - Code base started.
April 4, 2012 - Launching a WordPress template with POC. See Heat's getting started guide.
April 23, 2012 - Multiple Instance WordPress template v2-M1. See Heat's getting started guide.
May 14, 2012 - High Availability v3. See Heat's getting started guide.
June 27, 2012 - Ubuntu Support, High Availability improvements, more templates v4. See Heat's wiki for documentation to get started.