Abstract AWS namespaces out of Heat

Registered by Clint Byrum on 2013-03-07

Heat adoption by cloud providers be slowed by the fact that users will be required to advertise for the competition just to write a template. While the format of Heat templates is about as basic as it comes, users should be able to express any capability of Heat with OpenStack/Heat resources entirely. It should also be possible for someone deploying heat to disable the usage of the AWS namespace entirely.

Blueprint information

Status:
Complete
Approver:
None
Priority:
High
Drafter:
None
Direction:
Approved
Assignee:
Steven Dake
Definition:
Approved
Series goal:
None
Implementation:
Implemented
Milestone target:
None
Started by
Steven Hardy on 2013-07-31
Completed by
Angus Salkeld on 2015-02-03

Related branches

Whiteboard

sbaker: I'll be raising a separate blueprint for each resource that can have a native equivalent.

https://etherpad.openstack.org/havana-heat-abstract-aws

(zaneb) IMO this should take the form of an option in the configuration file. If AWS resources are disabled, just filter out all the resource types starting with "AWS::" when loading the plugins.

(jasond) Here's a related heat-cfntools change. The Metadata "init key" should be changed from "AWS::CloudFormation::Init" to something like "OS::Compute::Init" https://github.com/openstack/heat-cfntools/blob/master/heat_cfntools/cfntools/cfn_helper.py#L1010

(randallburt) @jasond I think we would want to keep that though. We still want CFN compatibility and AWS::CloudFormation::Init is be part of it. I don't think we need any special key at all for native stuff and just leverage cloud-init and/or "native" agents.

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.