diff options
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, 22 insertions, 0 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 new file mode 100644 index 0000000..e882ff6 --- /dev/null +++ b/tosca2heat/tosca-parser-0.3.0/toscaparser/tests/data/CSAR/tosca_single_instance_wordpress/README.txt @@ -0,0 +1,22 @@ +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. |