Jump to: navigation, search

Revision as of 02:49, 15 July 2012 by Sdake (talk) (fixed cut and past errors)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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

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