Revision as of 04:15, 15 July 2012

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

• Heat provides an AWS CloudFormation implementation for OpenStack that orchestrates an AWS CloudFormation template describing a cloud application by executing appropriate OpenStack API calls to generate running cloud applications.

Describe the relevance of the project to other OpenStack projects and the OpenStack mission to provide a ubiquitous cloud computing platform:

• The software integrates other core components of OpenStack into a one-file template system. The templates allow creation of most OpenStack resource types (such as instances, floating ips, volumes, security groups, users, etc), as well as some more advanced functionality such as instance high availability, instance autoscaling, and nested stacks. By providing very tight integration with other OpenStack core projects, all OpenStack core projects could receive a larger user base.
• 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 improving the appeal of OpenStack.

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.