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