OpenStack Heat

Abstract AWS namespaces out of Heat

Registered by Clint Byrum

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
Completed by
Angus Salkeld

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.