diff options
| author |   shangxdy <shang.xiaodong@zte.com.cn> | 2016-04-07 14:08:49 -0400 |
|---|---|---|
| committer | shangxdy <shang.xiaodong@zte.com.cn> | 2016-04-07 14:59:30 -0400 |
| commit | c8201c119ec686e79797721156767685fe848aca (patch) | |
| tree | cce6aa15ded38d89c18a14b76c21f21e0b1a24f7 /tosca2heat/tosca-parser-0.3.0/toscaparser/tests/data/CSAR/tosca_single_instance_wordpress/README.txt | |
| parent | 4e4c86a06d58b1816c074c7f9da4c58bbf10368c (diff) | |
Update tosca lib to version 0.5
Use tosca-parser and heat-translator to analyze to the basic
nfv-tosca type definitions, and use simple tosca new feature
such as policy, group and trigger, which are now supported by
the latest version of tosca-parser and heat-translator.
JIRA:PARSER-18
Change-Id: I797bcacbb5b32005d0aeb0f3f32851ac96e30f01
Signed--off-by: shangxdy <shang.xiaodong@zte.com.cn>
Signed-off-by: shangxdy <shang.xiaodong@zte.com.cn>
Diffstat (limited to 'tosca2heat/tosca-parser-0.3.0/toscaparser/tests/data/CSAR/tosca_single_instance_wordpress/README.txt')
| -rw-r--r-- | tosca2heat/tosca-parser-0.3.0/toscaparser/tests/data/CSAR/tosca_single_instance_wordpress/README.txt | 22 |
1 files changed, 0 insertions, 22 deletions
diff --git a/tosca2heat/tosca-parser-0.3.0/toscaparser/tests/data/CSAR/tosca_single_instance_wordpress/README.txt b/tosca2heat/tosca-parser-0.3.0/toscaparser/tests/data/CSAR/tosca_single_instance_wordpress/README.txt deleted file mode 100644 index e882ff6..0000000 --- a/tosca2heat/tosca-parser-0.3.0/toscaparser/tests/data/CSAR/tosca_single_instance_wordpress/README.txt +++ /dev/null @@ -1,22 +0,0 @@ -README: - -This CSAR contains all definitions that are required for deploying WordPress -and MySQL on a single compute instance. - -Entry information for processing through an orchestrator is contained in file -TOSCA-Metadata/TOSCA.meta. This file provides high-level information such as -CSAR version or creator of the CSAR. Furthermore, it provides pointers to the -various TOSCA definitions files that contain the real details. -The entry 'Entry-Definitions' points to the definitions file which holds the -service template for the workload. -'Entry-Definitions' is optional. An orchestrator can also process the contents -like this: -1) Read in and process each definitions file. -2) For each definitions file: - 2.1) Read in all * type definitions (node types, capability types, etc.) and - store them in an internal map -3) Verify and build dependencies (e.g. inheritance) between all type definitions - previously read in. Orchestrator built-in types (e.g. TOSCA base types) are - also considered in this step. -4) Process the actual service template (the file with a node_templates section). - Validate using previously obtained type information. |