Introduction

 Purpose

This is the functional specification proposal for blueprints as part of feature "PaaS Enablement: Composite Application Blueprints" which has Jira ID CLOUDSTACK-576.

What is being proposed is a new unit of deployment similar to a VMware vApp or AWS CloudFormation template. This unit has an abstract representation (blueprint/template) and a deployed instance representation (something like a project) that contains the related VMs, networks and other runtime resources.

References

• Bug References
  • Feature / Enhancement Request in Jira at CLOUDSTACK-576 (here)
  • Depends on the In-Guest Customization feature CLOUDSTACK-1026 (here)
• Code/Branch
  • Proposed work will be collated in `ahgittin/incubator-cloudstack` fork at github, `blueprints-XXXX` branch.
    (here)
  • It is TBD where and how this will be plugged in to CloudStack.
• Other Relevant Projects and Standards
  • Cloud Formation: http://aws.amazon.com/cloudformation/aws-cloudformation-templates/
  • OpenStack Heat: https://github.com/openstack/heat
  • OVA/OVF/vApp: http://www.dmtf.org/standards/ovf
  • TOSCA: https://www.oasis-open.org/committees/tosca/

 Document History

• 21 Jan 2013: Initial draft

Glossary

None yet

Feature Specifications

This feature is exposed via a REST API which initially supports:

• Create, list, update, and delete operations on a Blueprint
• Deploying a Blueprint, with parameters TBD (might be location, variables used in the Blueprint definition, and/or whether to deploy to a new or existing Project)

The Blueprint description language supports:

• create and start a set of VM's and selected network operations (TBD)
• specify configuration for these components
  • template ID
  • credentials for the VM's
  • network configuration, firewall and LB rules
  • selected properties of components and state are available elsewhere (e.g. IP address, whether it is online)
  • in-guest customization: files to install and commands to run at VM's, templated with properties from other blueprint components
  • order dependencies: where properties of some components must be available to perform other steps (e.g. plug DB IP address into Web tier VM)

The nature of the Blueprint description language is still evolving, and will be discussed in the section on "Architecture and Design Description" below.

The following features are deferred and not part of the work in scope at this stage, so that we can get feedback as early as possible, but the design of the description language should consider these as directions the project may go:

• GUI support for creating ("designing") Blueprints
• Portable descriptions of resources to be used (e.g. specifying templates by tags rather than ID, service offering by minRam, etc)
• "Clusters" (instance groups) which can be resized (cf nested blueprints)
• Management policies (e.g. failover, autoscaling) which may be attached, or perhaps managed by an additional deployed component

Use Cases

• An app team wants to have a single entity in Cloudstack which represents their application, consisting of a load-balancer, a scalable appserver tier, and a SQL database

• A middleware team wants to have a mechanism for describing a PaaS which they can deploy, manage (e.g. scale out, back), track costs, and destroy as a unit in Cloudstack

• A GUI user has built an application in a test environment which they want to extract as a re-usable component; they would like to create a blueprint from a project, in such a way that this blueprint could be re-deployed to a different environment

Architecture and Design Description

TODO

Appendix

Appendix A: Original Complete List of Features (Many Deferred)

• IaaS mapping
  • ability to refer to specific templates and offerings (eg id="1234")
  • ability to refer to portable descriptions of templates and offerings (eg os("ubuntu"), userdata("myappsrv"), minram("2gb"))
  • ability to define subnets, DNS, public IP, load-balancers, firewall rules

• Wiring
  • ability to write files to VM's with permissions, mode, etc
  • ability to embed references to other blueprint entities (ie other VM IP's/hostnames) in such files
  • ability to execute commands on VM's, with order constraints
  • ability to use puppet/chef/bash/juju/**cartridges/brooklyn (e.g. via the above capabilities)

• Management
  • ability to access blueprints and deployments via REST and via GUI
  • ability to define clusters and groups of entities (which could be scaled)
  • ability to deploy policies (eg elasticity, HA/DR logic) to various management systems
  • ability to deploy a blueprint to project (numerous people: should support "as new project" and "add to existing project", or no project)
  • ability to create a blueprint from project (koushik das and kelcey damage)
  • ability to destroy a deployed blueprint (assumes a record of deployed blueprint instances; if this maps on to a Project it is easy)