Heat/Vocabulary
< Heat
This is a comparison of the equivalent vocabulary for describing the primitives used during orchestration. The first column references This DSL.
See also: Heat/Vision
This is work in progress. Experts please amend as appropriate, and more comments at right or underneath.
This DSL | CFN | TOSCA | CAMP | - | Comments |
---|---|---|---|---|---|
Component | juju charm; puppet, chef roles | Node Template | Application Component, Platform Component | Maybe a AWS::CloudFormation::Init section at a stretch? Answer: no. | |
Blueprint | template | Service Template / Topology Template | Assembly Template | ||
Deployment | stack | service instance (note: the TOSCA spec does not explicitly define instance objects) | Assembly | ||
Static Resource | more properties/metadata | Deployment Artifact | Application Component Template | ||
Deployment Resource | resource | Node Template / Deployment Artifact | Application Component | Mostly the same | |
Options | Parameter declarations | Node- and Relationship Type Properties | |||
Inputs | Parameters | Properties defined in Node- and Relationship Templates | Parameters | CAMP Parameters = WIP | |
Constraints | Parameter constraints | Property Constraints or restrictions in XSD | |||
Provider | (none) | covered by Capabilities concept; instantiated Node Types could act as proviers, where the Node Type Implementation would be the provider implementation | (out of scope, related to requirements and capabilities) | Resource Plugin exposed so the user can choose the plugin they want? Answer: An abstraction for implementation details. | |
Environment | (none) | not defined; Requirements can be expressed against the environment | (out of scope, related to requirements and capabilities) | An Environment may span multiple providers in multiple clouds |
As reference: charts with TOSCA introduction presented at design summit in Portland: File:TOSCA in Heat - 20130415.pdf