Difference between revisions of "Heat/Vocabulary"
< Heat
Adrian Otto (talk | contribs) |
|||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | |||
This is a comparison of the equivalent vocabulary for describing the primitives used during orchestration. The first column references [[Heat/DSL|This DSL]]. | This is a comparison of the equivalent vocabulary for describing the primitives used during orchestration. The first column references [[Heat/DSL|This DSL]]. | ||
| − | + | See also: [[Heat/Vision]] | |
''This is work in progress. Experts please amend as appropriate, and more comments at right or underneath.'' | ''This is work in progress. Experts please amend as appropriate, and more comments at right or underneath.'' | ||
| Line 8: | Line 9: | ||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
| − | ! [[Heat/DSL|This DSL]] !! CFN !! TOSCA !! CAMP !! - !! Comments | + | ! [[Heat/DSL|This DSL]] !! CFN !! [https://www.oasis-open.org/committees/download.php/48397/TOSCA-v1.0-wd15.zip TOSCA] !! [http://docs.oasis-open.org/camp/camp-spec/v1.1/csd02/camp-spec-v1.1-csd02.pdf CAMP] !! - !! Comments |
|- | |- | ||
| − | | [[Heat/DSL# | + | | [[Heat/DSL#Component|Component]] || juju charm; puppet, chef roles || Node Template || Application Component, Platform Component || || Maybe a AWS::CloudFormation::Init section at a stretch? '''Answer''': no. |
|- | |- | ||
| − | | [[Heat/DSL# | + | | [[Heat/DSL#Heat_Blueprint|Blueprint]] || template || Service Template / Topology Template || Assembly Template || || |
|- | |- | ||
| − | | [[Heat/DSL# | + | | [[Heat/DSL#Deployment|Deployment]] || stack || service instance (note: the TOSCA spec does not explicitly define instance objects) || Assembly || || |
|- | |- | ||
| − | | [[Heat/DSL# | + | | [[Heat/DSL#Static_Resources_and_Deployment_Resources|Static Resource]] || more properties/metadata || Deployment Artifact || Application Component Template || || |
|- | |- | ||
| − | | [[Heat/DSL# | + | | [[Heat/DSL#Static_Resources_and_Deployment_Resources|Deployment Resource]] || resource || Node Template / Deployment Artifact || Application Component || || Mostly the same |
|- | |- | ||
| − | | [[Heat/DSL#Options_and_Inputs| | + | | [[Heat/DSL#Options_and_Inputs|Options]] || Parameter declarations || Node- and Relationship Type Properties || || || |
|- | |- | ||
| − | | [[Heat/DSL# | + | | [[Heat/DSL#Options_and_Inputs|Inputs]] || Parameters || Properties defined in Node- and Relationship Templates || Parameters || || CAMP Parameters = WIP |
|- | |- | ||
| − | | [[Heat/DSL# | + | | [[Heat/DSL#Options_and_Inputs|Constraints]] || Parameter constraints || Property Constraints or restrictions in XSD || || || |
|- | |- | ||
| − | | [[Heat/DSL# | + | | [[Heat/DSL#Providers|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. |
|- | |- | ||
| − | | [[Heat/DSL# | + | | [[Heat/DSL#Environment|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]] | ||
Latest revision as of 16:00, 19 April 2013
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
