summaryrefslogtreecommitdiffstats
path: root/docs/modelingconcepts
diff options
context:
space:
mode:
Diffstat (limited to 'docs/modelingconcepts')
-rw-r--r--docs/modelingconcepts/artifact-type.rst88
-rw-r--r--docs/modelingconcepts/cba.rst49
-rw-r--r--docs/modelingconcepts/data-dictionary.rst50
-rw-r--r--docs/modelingconcepts/data-type.rst163
-rw-r--r--docs/modelingconcepts/dynamic-payload.rst72
-rw-r--r--docs/modelingconcepts/enrichment.rst16
-rw-r--r--docs/modelingconcepts/expression.rst48
-rw-r--r--docs/modelingconcepts/external-system.rst120
-rw-r--r--docs/modelingconcepts/flexible-plug-in.rst122
-rw-r--r--docs/modelingconcepts/index.rst (renamed from docs/modelingconcepts/overview.rst)6
-rw-r--r--docs/modelingconcepts/node-type.rst841
-rw-r--r--docs/modelingconcepts/scripts.rst8
-rw-r--r--docs/modelingconcepts/southbound-interfaces.rst10
-rw-r--r--docs/modelingconcepts/template.rst6
-rw-r--r--docs/modelingconcepts/test.rst26
-rw-r--r--docs/modelingconcepts/tosca-meta.rst21
-rw-r--r--docs/modelingconcepts/workflow.rst338
17 files changed, 979 insertions, 1005 deletions
diff --git a/docs/modelingconcepts/artifact-type.rst b/docs/modelingconcepts/artifact-type.rst
index 8da7f59d1..3dda2c4ed 100644
--- a/docs/modelingconcepts/artifact-type.rst
+++ b/docs/modelingconcepts/artifact-type.rst
@@ -6,22 +6,22 @@
.. _artifact_type:
Artifact Type
--------------------------------------
+-------------
-Represents the **type of a artifact**, used to **identify** the
+Represents the **type of a artifact**, used to **identify** the
**implementation** of the functionality supporting this type of artifact.
`TOSCA definition <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454213>`_
This node was created, derived from ``tosca.artifacts.Root`` to be the root TOSCA node for all artifact.
-.. code-block:: JSON
+.. code-block:: json
:caption: **tosca.artifacts.Implementation**
{
- "description": "TOSCA base type for implementation artifacts",
- "version": "1.0.0",
- "derived_from": "tosca.artifacts.Root"
+ "description": "TOSCA base type for implementation artifacts",
+ "version": "1.0.0",
+ "derived_from": "tosca.artifacts.Root"
}
**Bellow is a list of supported artifact types**
@@ -38,24 +38,24 @@ This node was created, derived from ``tosca.artifacts.Root`` to be the root TOSC
File must have **.vtl** extension.
- The **template** can represent anything, such as device config, payload to interact with 3rd party systems,
+ The **template** can represent anything, such as device config, payload to interact with 3rd party systems,
:ref:`resource-accumulator template`, etc...
- Often a template will be **parameterized**, and each **parameter**
+ Often a template will be **parameterized**, and each **parameter**
must be defined within an mapping file (see 'Mapping' in this tab).
`Velocity reference document <http://velocity.apache.org/engine/1.7/user-guide.html>`_
- `Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/artifact_type/artifact-template-velocity.json>`_
+ `Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/artifact_type/artifact-template-velocity.json>`_
is the TOSCA artifact type:
- .. code-block:: JSON
+ .. code-block:: json
:caption: **artifact-template-velocity**
{
- "description": "TOSCA base type for implementation artifacts",
- "version": "1.0.0",
- "derived_from": "tosca.artifacts.Root"
+ "description": "TOSCA base type for implementation artifacts",
+ "version": "1.0.0",
+ "derived_from": "tosca.artifacts.Root"
}
.. tab:: Jinja
@@ -68,7 +68,7 @@ This node was created, derived from ``tosca.artifacts.Root`` to be the root TOSC
File must have **.jinja** extension.
- The **template** can represent **anything**, such as device config,
+ The **template** can represent **anything**, such as device config,
payload to interact with 3rd party systems, :ref:`resource-accumulator template`, etc...
Often a template will be parameterized, and each parameter must be defined within an :ref:`mapping file`.
@@ -78,16 +78,16 @@ This node was created, derived from ``tosca.artifacts.Root`` to be the root TOSC
`Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/artifact_type/artifact-template-jinja.json>`_
is the TOSCA artifact type:
- .. code-block:: JSON
+ .. code-block:: json
:caption: **artifact-template-jinja**
{
- "description": " Jinja Template used for Configuration",
- "version": "1.0.0",
- "file_ext": [
+ "description": " Jinja Template used for Configuration",
+ "version": "1.0.0",
+ "file_ext": [
"jinja"
- ],
- "derived_from": "tosca.artifacts.Implementation"
+ ],
+ "derived_from": "tosca.artifacts.Implementation"
}
.. tab:: Mapping
@@ -96,7 +96,7 @@ This node was created, derived from ``tosca.artifacts.Root`` to be the root TOSC
This type is meant to represent **mapping** files defining the **contract of each resource** to be resolved.
- Each **parameter** in a template **must** have a corresponding mapping definition,
+ Each **parameter** in a template **must** have a corresponding mapping definition,
modeled using datatype-resource-assignment (see :ref:`data_type`-> resources-asignment).
Hence the mapping file is meant to be a list of entries defined using datatype-resource-assignment
@@ -104,25 +104,25 @@ This node was created, derived from ``tosca.artifacts.Root`` to be the root TOSC
File must have **.json** extension.
- The **template** can represent **anything**, such as device config,
+ The **template** can represent **anything**, such as device config,
payload to interact with 3rd party systems, resource-accumulator template, etc...
`Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/artifact_type/artifact-mapping-resource.json>`_
is the TOSCA artifact type:
- .. code-block:: JSON
+ .. code-block:: json
:caption: **artifact-mapping-resource**
{
- "description": "Resource Mapping File used along with Configuration template",
- "version": "1.0.0",
- "file_ext": [
+ "description": "Resource Mapping File used along with Configuration template",
+ "version": "1.0.0",
+ "file_ext": [
"json"
- ],
- "derived_from": "tosca.artifacts.Implementation"
+ ],
+ "derived_from": "tosca.artifacts.Implementation"
}
-
- The mapping file basically contains a reference to the data dictionary to use
+
+ The mapping file basically contains a reference to the data dictionary to use
to resolve a particular resource.
The data dictionary defines the HOW and the mapping defines the WHAT.
@@ -131,23 +131,23 @@ This node was created, derived from ``tosca.artifacts.Root`` to be the root TOSC
Below are two examples using color coding to help understand the relationships.
- In orange is the information regarding the template. As mentioned before,
- template is part of the blueprint itself, and for the blueprint to know what template to use,
+ In orange is the information regarding the template. As mentioned before,
+ template is part of the blueprint itself, and for the blueprint to know what template to use,
the name has to match.
- In green is the relationship between the value resolved within the template,
+ In green is the relationship between the value resolved within the template,
and how it's mapped coming from the blueprint.
In blue is the relationship between a resource mapping to a data dictionary.
In red is the relationship between the resource name to be resolved and the HEAT environment variables.
- The key takeaway here is that whatever the value is for each color, it has to match all across.
- This means both right and left hand side are equivalent; it's all on the designer to express
+ The key takeaway here is that whatever the value is for each color, it has to match all across.
+ This means both right and left hand side are equivalent; it's all on the designer to express
the modeling for the service. That said, best practice is example 1.
- .. image:: ../media/dd_mapping_template_rel.png
- :scale: 100 %
+ .. image:: ../media/dd_mapping_template_rel.jpg
+ :width: 500pt
:align: center
.. tab:: Directed Graph
@@ -160,14 +160,14 @@ This node was created, derived from ``tosca.artifacts.Root`` to be the root TOSC
File must have **.xml** extension.
- Here is the list of executors currently supported (see here for explanation and full potential list:
+ Here is the list of executors currently supported (see here for explanation and full potential list:
`Service Logic Interpreter Nodes <https://wiki.onap.org/display/DW/Service+Logic+Interpreter+Nodes>`_
* execute
* block
* return
* break
- * exit
+ * exit
`Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/artifact_type/artifact-directed-graph.json>`_
is the TOSCA artifact type:
@@ -176,11 +176,11 @@ This node was created, derived from ``tosca.artifacts.Root`` to be the root TOSC
:caption: **artifact-directed-graph**
{
- "description": "Directed Graph File",
- "version": "1.0.0",
- "file_ext": [
+ "description": "Directed Graph File",
+ "version": "1.0.0",
+ "file_ext": [
"json",
"xml"
- ],
- "derived_from": "tosca.artifacts.Implementation"
+ ],
+ "derived_from": "tosca.artifacts.Implementation"
}
diff --git a/docs/modelingconcepts/cba.rst b/docs/modelingconcepts/cba.rst
index a89190b0d..41baa9924 100644
--- a/docs/modelingconcepts/cba.rst
+++ b/docs/modelingconcepts/cba.rst
@@ -2,14 +2,15 @@
.. This work is licensed under a Creative Commons Attribution 4.0
.. International License. http://creativecommons.org/licenses/by/4.0
.. Copyright (C) 2020 Deutsche Telekom AG.
+.. Copyright (C) 2020 AT&T.
.. _cba:
Controller Blueprint Archive (.cba)
--------------------------------------
+-----------------------------------
The **C**\ ontroller **B**\ lueprint **A**\ rchive is the overall service design, fully model-driven, intent based
-**package** needed for provisioning and configuration management automation.
+**package** needed for SELF SERVICE provisioning and configuration management automation.
The CBA is **.zip** file, comprised of the following folder structure, the files may vary:
@@ -17,22 +18,30 @@ The CBA is **.zip** file, comprised of the following folder structure, the files
.. code-block:: python
- ├── Definitions
- │ ├── blueprint.json Overall TOSCA service template (worfklow + node_template)
- │ ├── artifact_types.json (generated by enrichment)
- │ ├── data_types.json (generated by enrichment)
- │ ├── node_types.json (generated by enrichment)
- │ ├── relationship_types.json (generated by enrichment)
- │ └── resources_definition_types.json (generated by enrichment)
- ├── Environments Contains *.properties files as required by the service
- ├── Plans Contains Directed Graph
- ├── Tests Contains uat.yaml file for testing the cba actions within a cba **package
- ├── Scripts Contains scripts
- │ ├── python Python scripts
- │ └── kotlin Kotlin scripts
- ├── TOSCA-Metadata
- │ └── TOSCA.meta Meta-data of overall package
- └── Templates Contains combination of mapping and template
-
-To process a CBA for any service we need to enrich it first. This will gather all the node- type, data-type,
+ ├── Definitions
+ │ ├── blueprint.json Overall TOSCA service template (workflow + node_template)
+ │ ├── artifact_types.json (generated by enrichment)
+ │ ├── data_types.json (generated by enrichment)
+ │ ├── policy_types.json (generated by enrichment)
+ │ ├── node_types.json (generated by enrichment)
+ │ ├── relationship_types.json (generated by enrichment)
+ │ ├── resources_definition_types.json (generated by enrichment, based on Data Dictionaries)
+ │ └── *-mapping.json One per Template
+ │
+ ├── Environments Contains *.properties files as required by the service
+ │
+ ├── Plans Contains Directed Graph
+ │
+ ├── Tests Contains uat.yaml file for testing cba actions within a cba package
+ │
+ ├── Scripts Contains scripts
+ │ ├── python Python scripts
+ │ └── kotlin Kotlin scripts
+ │
+ ├── TOSCA-Metadata
+ │ └── TOSCA.meta Meta-data of overall package
+ │
+ └── Templates Contains combination of mapping and template
+
+To process a CBA for any service we need to enrich it first. This will gather all the node- type, data-type,
artifact-type, data-dictionary definitions provided in the blueprint.json. \ No newline at end of file
diff --git a/docs/modelingconcepts/data-dictionary.rst b/docs/modelingconcepts/data-dictionary.rst
index af0f89797..bfc86d0c9 100644
--- a/docs/modelingconcepts/data-dictionary.rst
+++ b/docs/modelingconcepts/data-dictionary.rst
@@ -6,7 +6,7 @@
.. _data_dictionary:
Data Dictionary
------------------
+---------------
A data dictionary **models the how** a specific **resource** can be **resolved**.
@@ -32,7 +32,7 @@ As part of modelling a data dictionary entry, the following generic information
- The creator
- Mandatory
* - tags
- - Information related
+ - Information related
- Mandatory
* - sources
- List of resource source instance (see :ref:`resource source`)
@@ -42,11 +42,11 @@ As part of modelling a data dictionary entry, the following generic information
- Mandatory
* - name
- Data dictionary name
- - Mandatory
-
+ - Mandatory
+
**Bellow are properties that all the resource source can have**
-The modeling does allow for **data translation** between external capability
+The modeling does allow for **data translation** between external capability
and CDS for both input and output key mapping.
.. list-table::
@@ -57,22 +57,22 @@ and CDS for both input and output key mapping.
- Description
- Scope
* - input-key-mapping
- - map of resources required to perform the request/query. The left hand-side is what is used within
+ - map of resources required to perform the request/query. The left hand-side is what is used within
the query/request, the right hand side refer to a data dictionary instance.
- Optional
* - output-key-mapping
- - name of the resource to be resolved mapped to the value resolved by the request/query.
+ - name of the resource to be resolved mapped to the value resolved by the request/query.
- Optional
* - key-dependencies
- | list of data dictionary instances to be resolved prior the resolution of this specific resource.
- | during run time execution the key dependencies are recursively sorted and resolved
- in batch processing using the `acyclic graph algorithm
+ | during run time execution the key dependencies are recursively sorted and resolved
+ in batch processing using the `acyclic graph algorithm
<https://en.wikipedia.org/wiki/Directed_acyclic_graph>`_
- Optional
-
+
**Example:**
-``vf-module-model-customization-uuid`` and ``vf-module-label`` are two data dictionaries.
+``vf-module-model-customization-uuid`` and ``vf-module-label`` are two data dictionaries.
A SQL table, VF_MODULE_MODEL, exist to correlate them.
Here is how input-key-mapping, output-key-mapping and key-dependencies can be used:
@@ -82,32 +82,30 @@ Here is how input-key-mapping, output-key-mapping and key-dependencies can be us
:header-rows: 1
* - vf-module-label data dictionary
- * - .. code-block:: JSON
+ * - .. code-block:: json
-
- {
+ {
"name" : "vf-module-label",
"tags" : "vf-module-label",
"updated-by" : "adetalhouet",
"property" : {
- "description" : "vf-module-label",
- "type" : "string"
+ "description" : "vf-module-label",
+ "type" : "string"
},
"sources" : {
- "primary-db" : {
- "type" : "source-primary-db",
- "properties" : {
+ "primary-db" : {
+ "type" : "source-primary-db",
+ "properties" : {
"type" : "SQL",
- "query" : "select sdnctl.VF_MODULE_MODEL.vf_module_label as vf_module_label
- from sdnctl.VF_MODULE_MODEL where sdnctl.VF_MODULE_MODEL.customization_uuid=:customizationid",
+ "query" : "select sdnctl.VF_MODULE_MODEL.vf_module_label as vf_module_label from sdnctl.VF_MODULE_MODEL where sdnctl.VF_MODULE_MODEL.customization_uuid=:customizationid",
"input-key-mapping" : {
- "customizationid" : "vf-module-model-customization-uuid"
+ "customizationid" : "vf-module-model-customization-uuid"
},
"output-key-mapping" : {
- "vf-module-label" : "vf_module_label"
+ "vf-module-label" : "vf_module_label"
},
"key-dependencies" : [ "vf-module-model-customization-uuid" ]
- }
- }
+ }
+ }
}
- } \ No newline at end of file
+ } \ No newline at end of file
diff --git a/docs/modelingconcepts/data-type.rst b/docs/modelingconcepts/data-type.rst
index 72eb12591..29143de80 100644
--- a/docs/modelingconcepts/data-type.rst
+++ b/docs/modelingconcepts/data-type.rst
@@ -6,7 +6,7 @@
.. _data_type:
Data type
--------------------------------------
+---------
Represents the **schema** of a specific type of **data**.
@@ -28,6 +28,7 @@ Supports both **primitive** and **complex** data types:
- * json
* list
* array
+
For complex data type, an **entry schema** is required, defining the
type of value contained within the complex type, if list or array.
@@ -37,61 +38,47 @@ Users can **create** as many **data type** as needed.
**Creating Custom Data Types:**
- To create a custom data-type you can use a POST call to CDS endpoint:
+ To create a custom data-type you can use a POST call to CDS endpoint:
"<cds-ip>:<cds-port>/api/v1/model-type"
.. code-block:: python
:caption: **Payload:**
{
-
- "model-name": "<model-name>",
- "derivedFrom": "tosca.datatypes.Root",
-
- "definitionType": "data_type",
-
- "definition": {
-
+ "model-name": "<model-name>",
+ "derivedFrom": "tosca.datatypes.Root",
+ "definitionType": "data_type",
+ "definition": {
"description": "<description>",
-
"version": "<version-number: eg 1.0.0>",
-
"properties": {<add properties of your custom data type in JSON format>},
-
"derived_from": "tosca.datatypes.Root"
-
- },
-
- "description": "<description",
-
- "version": "<version>",
-
- "tags": "<model-name>,datatypes.Root.data_type",
-
- "creationDate": "<creation timestamp>",
-
- "updatedBy": "<name>"
-
+ },
+ "description": "<description",
+ "version": "<version>",
+ "tags": "<model-name>,datatypes.Root.data_type",
+ "creationDate": "<creation timestamp>",
+ "updatedBy": "<name>"
}
-Data type are useful to manipulate data during resource resolution.
+Data type are useful to manipulate data during resource resolution.
They can be used to format the JSON output as needed.
-List of existing data type:
+List of existing data type:
`<https://github.com/onap/ccsdk-cds/tree/master/components/model-catalog/definition-type/starter-type/data_type>`_
-`TOSCA specification
+`TOSCA specification
<http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454187>`_
**Below is a list of existing data types**
.. tabs::
-
+
.. tab:: resource-assignment
**datatype-resource-assignment**
- Used to define entries within artifact-mapping-resource
+ Used to define entries within artifact-mapping-resource
(see tab Artifact Type -> artifact-mapping-resource)
That datatype represent a **resource** to be resolved. We also refer
@@ -121,47 +108,47 @@ List of existing data type:
`<https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/data_type/datatype-resource-assignment.json>`_
- .. code-block:: JSON
+ .. code-block:: json
:caption: **datatype-resource-assignment**
- {
+ {
"version": "1.0.0",
"description": "This is Resource Assignment Data Type",
"properties": {
- "property": {
- "required": true,
- "type": "datatype-property"
- },
- "input-param": {
- "required": true,
- "type": "boolean"
- },
- "dictionary-name": {
- "required": false,
- "type": "string"
- },
- "dictionary-source": {
- "required": false,
- "type": "string"
- },
- "dependencies": {
- "required": true,
- "type": "list",
- "entry_schema": {
- "type": "string"
- }
- },
- "updated-date": {
- "required": false,
- "type": "string"
- },
- "updated-by": {
- "required": false,
- "type": "string"
- }
+ "property": {
+ "required": true,
+ "type": "datatype-property"
+ },
+ "input-param": {
+ "required": true,
+ "type": "boolean"
+ },
+ "dictionary-name": {
+ "required": false,
+ "type": "string"
+ },
+ "dictionary-source": {
+ "required": false,
+ "type": "string"
+ },
+ "dependencies": {
+ "required": true,
+ "type": "list",
+ "entry_schema": {
+ "type": "string"
+ }
+ },
+ "updated-date": {
+ "required": false,
+ "type": "string"
+ },
+ "updated-by": {
+ "required": false,
+ "type": "string"
+ }
},
"derived_from": "tosca.datatypes.Root"
- }
+ }
.. tab:: property
@@ -188,44 +175,44 @@ List of existing data type:
`<https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/data_type/datatype-property.json>`_
- .. code-block:: JSON
+ .. code-block:: json
:caption: **datatype-property**
{
- "version": "1.0.0",
- "description": "This is Resource Assignment Data Type",
- "properties": {
+ "version": "1.0.0",
+ "description": "This is Resource Assignment Data Type",
+ "properties": {
"property": {
- "required": true,
- "type": "datatype-property"
+ "required": true,
+ "type": "datatype-property"
},
"input-param": {
- "required": true,
- "type": "boolean"
+ "required": true,
+ "type": "boolean"
},
"dictionary-name": {
- "required": false,
- "type": "string"
+ "required": false,
+ "type": "string"
},
"dictionary-source": {
- "required": false,
- "type": "string"
+ "required": false,
+ "type": "string"
},
"dependencies": {
- "required": true,
- "type": "list",
- "entry_schema": {
- "type": "string"
- }
+ "required": true,
+ "type": "list",
+ "entry_schema": {
+ "type": "string"
+ }
},
"updated-date": {
- "required": false,
- "type": "string"
+ "required": false,
+ "type": "string"
},
"updated-by": {
- "required": false,
- "type": "string"
+ "required": false,
+ "type": "string"
}
- },
- "derived_from": "tosca.datatypes.Root"
+ },
+ "derived_from": "tosca.datatypes.Root"
} \ No newline at end of file
diff --git a/docs/modelingconcepts/dynamic-payload.rst b/docs/modelingconcepts/dynamic-payload.rst
index a2a4cb72b..8f378c069 100644
--- a/docs/modelingconcepts/dynamic-payload.rst
+++ b/docs/modelingconcepts/dynamic-payload.rst
@@ -4,7 +4,7 @@
.. Copyright (C) 2020 Deutsche Telekom AG.
Dynamic Payload
--------------------------------------
+---------------
One of the most important API provided by the run time is to execute a CBA Package.
@@ -21,45 +21,45 @@ Here is how the a **generic request** and **response** look like.
- response
* - .. code-block:: json
- {
- "commonHeader": {
- "originatorId": "",
- "requestId": "",
- "subRequestId": ""
- },
- "actionIdentifiers": {
- "blueprintName": "",
- "blueprintVersion": "",
- "actionName": "",
- "mode": ""
- },
- "payload": {
- "$actionName-request": {
- "$actionName-properties": {
- }
+ {
+ "commonHeader": {
+ "originatorId": "",
+ "requestId": "",
+ "subRequestId": ""
+ },
+ "actionIdentifiers": {
+ "blueprintName": "",
+ "blueprintVersion": "",
+ "actionName": "",
+ "mode": ""
+ },
+ "payload": {
+ "$actionName-request": {
+ "$actionName-properties": {
}
- }
+ }
}
+ }
- .. code-block:: json
-
- {
- "commonHeader": {
- "originatorId": "",
- "requestId": "",
- "subRequestId": ""
- },
- "actionIdentifiers": {
- "blueprintName": "",
- "blueprintVersion": "",
- "actionName": "",
- "mode": ""
- },
- "payload": {
- "$actionName-response": {
- }
- }
+
+ {
+ "commonHeader": {
+ "originatorId": "",
+ "requestId": "",
+ "subRequestId": ""
+ },
+ "actionIdentifiers": {
+ "blueprintName": "",
+ "blueprintVersion": "",
+ "actionName": "",
+ "mode": ""
+ },
+ "payload": {
+ "$actionName-response": {
+ }
}
+ }
The ``actionName``, under the ``actionIdentifiers`` refers to the name of a
Workflow (see :ref:`workflow`)
@@ -74,5 +74,5 @@ Then the **content within this element** is fully based on the
During the :ref:`enrichment` CDS will aggregate all the resources
defined to be resolved as input (see :ref:`node_type` -> Source -> Input), within mapping definition files
-(see :ref:`artifact_type` -> Mapping), as data-type, that will then be use as type
+(see :ref:`artifact_type` -> Mapping), as data-type, that will then be use as type
of an input called ``$actionName-properties``. \ No newline at end of file
diff --git a/docs/modelingconcepts/enrichment.rst b/docs/modelingconcepts/enrichment.rst
index 1533debe9..b88493448 100644
--- a/docs/modelingconcepts/enrichment.rst
+++ b/docs/modelingconcepts/enrichment.rst
@@ -6,7 +6,7 @@
.. _enrichment:
Enrichment
------------
+----------
The idea is that the CBA is a self-sufficient package, hence requires
all the various types definition its using.
@@ -22,22 +22,22 @@ definition of types used:
* gather all the node-type used and put them into a :file:`node_types.json` file
* gather all the data-type used and put them into a :file:`data_types.json` file
* gather all the artifact-type used and put them into a :file:`artifact_types.json` file
-* gather all the data dictionary definitions used from within the mapping files and put them
+* gather all the data dictionary definitions used from within the mapping files and put them
into a :file:`resources_definition_types.json` file
.. warning::
- Before uploading a CBA, it must be enriched. If your package is already enrich,
+ Before uploading a CBA, it must be enriched. If your package is already enrich,
you do not need to perform enrichment again.
-The enrichment can be run using REST API, and required the **.zip** file as input.
+The enrichment can be run using REST API, and required the **.zip** file as input.
It will return an :file:`enriched-cba.zip` file.
.. code-block:: bash
curl -X POST \
- 'http://{{ip}}:{{cds-designtime}}/api/v1/blueprint-model/enrich' \
- -H 'content-type: multipart/form-data' \
- -F file=@cba.zip
+ 'http://{{ip}}:{{cds-designtime}}/api/v1/blueprint-model/enrich' \
+ -H 'content-type: multipart/form-data' \
+ -F file=@cba.zip
The enrichment process will also, for all resources to be resolved as input and default:
@@ -46,7 +46,7 @@ The enrichment process will also, for all resources to be resolved as input and
Example for workflow named *resource-assignment*:
-.. code-block:: JSON
+.. code-block:: json
:caption: **dynamic input**
{
diff --git a/docs/modelingconcepts/expression.rst b/docs/modelingconcepts/expression.rst
index 27d9de5d4..059cf7cd1 100644
--- a/docs/modelingconcepts/expression.rst
+++ b/docs/modelingconcepts/expression.rst
@@ -7,7 +7,7 @@
.. _expression:
Expression
--------------------------------------
+----------
TOSCA provides for a set of functions to reference elements within the template or to retrieve runtime values.
@@ -19,54 +19,56 @@ TOSCA provides for a set of functions to reference elements within the template
**get_input**
- The **get_input** function is used to retrieve the values of properties declared
+ The **get_input** function is used to retrieve the values of properties declared
within the inputs section of a TOSCA Service Template.
Within CDS, this is mainly Workflow inputs.
- `TOSCA specification
+ `TOSCA specification
<http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454178>`_
**Example:**
`<https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/blueprint-model/test-blueprint/golden/Definitions/golden-blueprint.json#L210>`_
- .. code-block:: JSON
-
+ .. code-block:: json
+
"resolution-key": {
- "get_input": "resolution-key"
+ "get_input": "resolution-key"
}
-
+
.. tab:: get_property
**get_property**
- The **get_property** function is used to retrieve property values between modelable
+ The **get_property** function is used to retrieve property values between modelable
entities defined in the same service template.
- `TOSCA specification
+ `TOSCA specification
<http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454178>`_
**Example:**
- TBD
+ .. code-block:: json
+
+ "get_property": ["SELF", "property-name"]
.. tab:: get_attribute
**get_attribute**
- The **get_attribute** function is used to retrieve the values of named attributes declared
+ The **get_attribute** function is used to retrieve the values of named attributes declared
by the referenced node or relationship template name.
- `TOSCA specification
+ `TOSCA specification
<http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454178>`_
**Example:**
`<https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/blueprint-model/test-blueprint/golden/Definitions/golden-blueprint.json#L64-L67>`_
- .. code-block:: JSON
-
+ .. code-block:: json
+
"get_attribute": [
"resource-assignment",
"assignment-params"
@@ -76,26 +78,30 @@ TOSCA provides for a set of functions to reference elements within the template
**get_operation_output**
- The **get_operation_output** function is used to retrieve property values between modelable
- entities defined in the same service template.
+ The **get_operation_output** function is used to retrieve the values of variables
+ exposed / exported from an interface operation.
- `TOSCA specification
+ `TOSCA specification
<http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454180>`_
**Example:**
- TBD
+ .. code-block:: json
+
+ "get_operation_output": ["SELF", "interface-name", "operation-name", "output-property-name"]
.. tab:: get_artifact
**get_artifact**
- The **get_artifact** function is used to retrieve property values between modelable
+ The **get_artifact** function is used to retrieve artifact location between modelable
entities defined in the same service template.
- `TOSCA specification
+ `TOSCA specification
<http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454182>`_
**Example:**
- TBD \ No newline at end of file
+ .. code-block:: json
+
+ "get_artifact" : ["SELF", "artifact-template", "location", true] \ No newline at end of file
diff --git a/docs/modelingconcepts/external-system.rst b/docs/modelingconcepts/external-system.rst
new file mode 100644
index 000000000..806600f4d
--- /dev/null
+++ b/docs/modelingconcepts/external-system.rst
@@ -0,0 +1,120 @@
+.. This work is a derivative of https://wiki.onap.org/display/DW/Modeling+Concepts#Concepts-2026349199
+.. This work is licensed under a Creative Commons Attribution 4.0
+.. International License. http://creativecommons.org/licenses/by/4.0
+.. Copyright (C) 2020 Deutsche Telekom AG.
+
+External Systems support
+------------------------
+
+Interaction with **external systems** is made **dynamic** and **plug-able**
+removing development cycle to support new endpoint.
+In order to share the external system information, TOSCA provides a way to create macros using **dsl_definitions**:
+Link to TOSCA spec:
+`info 1 <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454160>`_,
+`info 2 <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454173>`_.
+
+Use cases:
+* Resource resolution using **REST** (see tab Node Type) or **SQL** (see tab Node Type) external systems
+* **gRPC** is supported for remote execution
+* Any REST endpoint can be dynamically injected as part of the scripting framework.
+
+Here are some examples on how to populate the system information within the package:
+
+.. list-table::
+ :widths: 100
+ :header-rows: 1
+
+ * - token-auth
+ * - .. code-block:: json
+
+ {
+ . . .
+ "dsl_definitions": {
+ "ipam-1": {
+ "type": "token-auth",
+ "url": "http://netbox-nginx.netprog:8080",
+ "token": "Token 0123456789abcdef0123456789abcdef01234567"
+ }
+ }
+
+.. list-table::
+ :widths: 100
+ :header-rows: 1
+
+ * - basic-auth
+ * - .. code-block:: json
+
+ {
+ . . .
+ "dsl_definitions": {
+ "ipam-1": {
+ "type": "basic-auth",
+ "url": "http://localhost:8080",
+ "username": "bob",
+ "password": "marley"
+ }
+ }
+ . . .
+ }
+
+.. list-table::
+ :widths: 100
+ :header-rows: 1
+
+ * - ssl-basic-auth
+ * - .. code-block:: json
+
+ {
+ . . .
+ "dsl_definitions": {
+ "ipam-1": {
+ "type" : "ssl-basic-auth",
+ "url" : "http://localhost:32778",
+ "keyStoreInstance": "JKS or PKCS12",
+ "sslTrust": "trusture",
+ "sslTrustPassword": "trustore password",
+ "sslKey": "keystore",
+ "sslKeyPassword: "keystore password"
+ }
+ }
+ . . .
+ }
+
+.. list-table::
+ :widths: 100
+ :header-rows: 1
+
+ * - grpc-executor
+ * - .. code-block:: json
+
+ {
+ . . .
+ "dsl_definitions": {
+ "remote-executor": {
+ "type": "token-auth",
+ "host": "cds-command-executor.netprog",
+ "port": "50051",
+ "token": "Basic Y2NzZGthcHBzOmNjc2RrYXBwcw=="
+ }
+ }
+ . . .
+ }
+
+.. list-table::
+ :header-rows: 1
+
+ * - maria-db
+ * - .. code-block:: json
+
+ {
+ . . .
+ "dsl_definitions": {
+ "netprog-db": {
+ "type": "maria-db",
+ "url": "jdbc:mysql://10.195.196.123:32050/netprog",
+ "username": "netprog",
+ "password": "netprog"
+ }
+ }
+ . . .
+ }
diff --git a/docs/modelingconcepts/flexible-plug-in.rst b/docs/modelingconcepts/flexible-plug-in.rst
deleted file mode 100644
index 62749dcec..000000000
--- a/docs/modelingconcepts/flexible-plug-in.rst
+++ /dev/null
@@ -1,122 +0,0 @@
-.. This work is a derivative of https://wiki.onap.org/display/DW/Modeling+Concepts#Concepts-2026349199
-.. This work is licensed under a Creative Commons Attribution 4.0
-.. International License. http://creativecommons.org/licenses/by/4.0
-.. Copyright (C) 2020 Deutsche Telekom AG.
-
-External Systems support
--------------------------------------
-
-Interaction with **external systems** is made **dynamic**, removing
-development cycle to support new endpoint.
-
-In order to define the external system information, TOSCA provides
-**dsl_definitions**. Link to TOSCA spec `info 1
-<http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454160>`_,
-`info 2 <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454173>`_.
-
-Use cases:
-
-* Resource resolution using **REST** (see tab Node Type) or **SQL** (see tab Node Type) external systems
-* **gRPC** is supported for remote execution
-* Any REST endpoint can be dynamically injected as part of the scripting framework.
-
-Here are some examples on how to populate the system information within the package:
-
-.. list-table::
- :widths: 100
- :header-rows: 1
-
- * - token-auth
- * - .. code-block:: JSON
-
- {
- . . .
- "dsl_definitions": {
- "ipam-1": {
- "type": "token-auth",
- "url": "http://netbox-nginx.netprog:8080",
- "token": "Token 0123456789abcdef0123456789abcdef01234567"
- }
- }
-
-.. list-table::
- :widths: 100
- :header-rows: 1
-
- * - basic-auth
- * - .. code-block:: JSON
-
- {
- . . .
- "dsl_definitions": {
- "ipam-1": {
- "type": "basic-auth",
- "url": "http://localhost:8080",
- "username": "bob",
- "password": "marley"
- }
- }
- . . .
- }
-
-.. list-table::
- :widths: 100
- :header-rows: 1
-
- * - ssl-basic-auth
- * - .. code-block:: JSON
-
- {
- . . .
- "dsl_definitions": {
- "ipam-1": {
- "type" : "ssl-basic-auth",
- "url" : "http://localhost:32778",
- "keyStoreInstance": "JKS or PKCS12",
- "sslTrust": "trusture",
- "sslTrustPassword": "trustore password",
- "sslKey": "keystore",
- "sslKeyPassword: "keystore password"
- }
- }
- . . .
- }
-
-.. list-table::
- :widths: 100
- :header-rows: 1
-
- * - grpc-executor
- * - .. code-block:: JSON
-
- {
- . . .
- "dsl_definitions": {
- "remote-executor": {
- "type": "token-auth",
- "host": "cds-command-executor.netprog",
- "port": "50051",
- "token": "Basic Y2NzZGthcHBzOmNjc2RrYXBwcw=="
- },
- }
- . . .
- }
-
-.. list-table::
- :header-rows: 1
-
- * - maria-db
- * - .. code-block:: JSON
-
- {
- . . .
- "dsl_definitions": {
- "netprog-db": {
- "type": "maria-db",
- "url": "jdbc:mysql://10.195.196.123:32050/netprog",
- "username": "netprog",
- "password": "netprog"
- }
- }
- . . .
- } \ No newline at end of file
diff --git a/docs/modelingconcepts/overview.rst b/docs/modelingconcepts/index.rst
index 2ca70c719..1b9d93c98 100644
--- a/docs/modelingconcepts/overview.rst
+++ b/docs/modelingconcepts/index.rst
@@ -4,7 +4,7 @@
.. Copyright (C) 2020 Deutsche Telekom AG.
Modeling Concepts
-==================
+=================
CDS is a framework to automate the **resolution of resources** for
**instantiation** and any **config** provisioning operation, such as
@@ -29,11 +29,11 @@ can be found
:caption: Table of Contents
:maxdepth: 1
- CBA <cba>
+ cba
Tosca.Meta <tosca-meta>
dynamic-payload
enrichment
- Flexible Plug-in <flexible-plug-in>
+ external-system
expression
data-dictionary
data-type
diff --git a/docs/modelingconcepts/node-type.rst b/docs/modelingconcepts/node-type.rst
index 4c2e7f7fc..070f6f65c 100644
--- a/docs/modelingconcepts/node-type.rst
+++ b/docs/modelingconcepts/node-type.rst
@@ -6,12 +6,12 @@
.. _node_type:
Node type
------------
+---------
-`TOSCA definition
+`TOSCA definition
<http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454215>`_
-In CDS, we have mainly two distinct types: components and source. We have some other type as well,
+In CDS, we have mainly two distinct types: components and source. We have some other type as well,
listed in the other section.
.. tabs::
@@ -22,41 +22,41 @@ listed in the other section.
Used to represent a **functionality** along with its **contract**, such as **inputs**, **ouputs**, and **attributes**
- `Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/node_type/tosca.nodes.Component.json>`_
+ `Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/node_type/tosca.nodes.Component.json>`_
is the root component TOSCA node type from which other node type will derive:
-
+
.. code-block:: json
:caption: **tosca.nodes.Component**
{
- "description": "This is default Component Node",
- "version": "1.0.0",
- "derived_from": "tosca.nodes.Root"
+ "description": "This is default Component Node",
+ "version": "1.0.0",
+ "derived_from": "tosca.nodes.Root"
}
**Bellow is a list of supported components**
.. tabs::
-
+
.. tab:: resource-resolution
**component-resource-resolution:**
Used to perform resolution of **resources**.
- Requires as many as artifact-mapping-resource (see :ref:`artifact_type` -> Mapping) AND
+ Requires as many as artifact-mapping-resource (see :ref:`artifact_type` -> Mapping) AND
artifact-template-velocity (see :ref:`artifact_type` -> Jinja) as needed.
**Output result:**
Will put the resolution result as an **attribute** in the workflow context called **assignment-params**.
- Using the :ref:`undefined <get_attribute expression>`, this attribute can be retrieve to be
+ Using the :ref:`undefined <get_attribute expression>`, this attribute can be retrieve to be
provided as workflow output (see :ref:`workflow`).
**Specify which template to resolve:**
- Currently, resolution is bounded to a template. To specify which template to use, you
+ Currently, resolution is bounded to a template. To specify which template to use, you
need to fill in the `artifact-prefix-names` field.
See :ref:`template` to understand what the artifact prefix name is.
@@ -67,36 +67,36 @@ listed in the other section.
Also, when storing the data, it must be in the context of either a `resource-id` and `resource-type`, or based on a given `resolution-key`
-
- The concept of resource-id / resource-type, or resolution-key, is to uniquely identify a specific resolution that
+
+ The concept of resource-id / resource-type, or resolution-key, is to uniquely identify a specific resolution that
has been performed for a given action. Hence the resolution-key has to be unique for a given blueprint name, blueprint version, action name.
Through the combination of the fields mentioned previously, one could retrieved what has been resolved. This is useful to manage the life-cycle of the resolved resource, the life-cycle of the template, along with sharing with external systems the outcome of a given resolution.
The resource-id / resource-type combo is more geared to uniquely identify a resource in AAI, or external system. For example, for a given AAI resource, say a PNF, you can trigger a given CDS action, and then you will be able to manage all the resolved resources bound to this PNF. Even we could have a history of what has been assigned, unassigned for this given AAI resource.
- .. warning:: Important not to confuse and AAI resource (e.g. a topology element,
- or service related element) with the resources resolved by CDS, which can be seen
+ .. warning:: Important not to confuse and AAI resource (e.g. a topology element,
+ or service related element) with the resources resolved by CDS, which can be seen
as parameters required to derived a network configuration.
**Run the resolution multiple time:**
- If you need to run the same resolution component multiple times, use the field `occurence`.
- This will add the notion of occurrence to the resolution, and if storing the results, resources
+ If you need to run the same resolution component multiple times, use the field `occurence`.
+ This will add the notion of occurrence to the resolution, and if storing the results, resources
and templates, they will be accessible for each occurrence.
- Occurrence is a number between 1 and N; when retrieving information
+ Occurrence is a number between 1 and N; when retrieving information
for a given occurrence, the first iteration starts at 1.
This feature is useful when you need to apply the same configuration accross network elements.
- `Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/node_type/component-resource-resolution.json>`_
+ `Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/node_type/component-resource-resolution.json>`_
is the definition:
.. code-block:: json
- :caption: **component-resource-resolution**
+ :caption: **component-resource-resolution**
- {
+ {
"description": "This is Resource Assignment Component API",
"version": "1.0.0",
"attributes": {
@@ -180,20 +180,20 @@ listed in the other section.
}
},
"derived_from": "tosca.nodes.Component"
- }
+ }
.. tab:: script-executor
**component-script-executor:**
- Used to **execute** a script to perform **NETCONF, RESTCONF, SSH commands**
+ Used to **execute** a script to perform **NETCONF, RESTCONF, SSH commands**
from within the runtime container of CDS.
Two type of scripts are supported:
- * Kotlin: offer a way more integrated scripting framework, along
+ * Kotlin: offer a way more integrated scripting framework, along
with a way faster processing capability. See more about Kotlin script: https://github.com/Kotlin/KEEP/blob/master/proposals/scripting-support.md
- * Python: uses Jython which is bound to Python 2.7, end of life Januray 2020.
+ * Python: uses Jython which is bound to Python 2.7, end of life Januray 2020.
See more about Jython: https://www.jython.org/
The `script-class-reference` field need to reference
@@ -207,60 +207,60 @@ listed in the other section.
.. _test_test_test:
.. code-block:: json
- :caption: **component-script-executor**
+ :caption: **component-script-executor**
- {
- "description": "This is Netconf Transaction Configuration Component API",
- "version": "1.0.0",
- "interfaces": {
- "ComponentScriptExecutor": {
+ {
+ "description": "This is Netconf Transaction Configuration Component API",
+ "version": "1.0.0",
+ "interfaces": {
+ "ComponentScriptExecutor": {
"operations": {
- "process": {
- "inputs": {
+ "process": {
+ "inputs": {
"script-type": {
- "description": "Script type, kotlin type is supported",
- "required": true,
- "type": "string",
- "default": "internal",
- "constraints": [
- {
+ "description": "Script type, kotlin type is supported",
+ "required": true,
+ "type": "string",
+ "default": "internal",
+ "constraints": [
+ {
"valid_values": [
- "kotlin",
- "jython",
- "internal"
+ "kotlin",
+ "jython",
+ "internal"
]
- }
- ]
+ }
+ ]
},
"script-class-reference": {
- "description": "Kotlin Script class name with full package or jython script name.",
- "required": true,
- "type": "string"
- },
+ "description": "Kotlin Script class name with full package or jython script name.",
+ "required": true,
+ "type": "string"
+ },
"dynamic-properties": {
- "description": "Dynamic Json Content or DSL Json reference.",
- "required": false,
- "type": "json"
+ "description": "Dynamic Json Content or DSL Json reference.",
+ "required": false,
+ "type": "json"
}
- },
- "outputs": {
+ },
+ "outputs": {
"response-data": {
- "description": "Execution Response Data in JSON format.",
- "required": false,
- "type": "string"
+ "description": "Execution Response Data in JSON format.",
+ "required": false,
+ "type": "string"
},
"status": {
- "description": "Status of the Component Execution ( success or failure )",
- "required": true,
- "type": "string"
+ "description": "Status of the Component Execution ( success or failure )",
+ "required": true,
+ "type": "string"
}
- }
- }
+ }
+ }
}
- }
- },
- "derived_from": "tosca.nodes.Component"
- }
+ }
+ },
+ "derived_from": "tosca.nodes.Component"
+ }
.. tab:: remote-script-executor
@@ -274,134 +274,133 @@ listed in the other section.
execute-command-logs: will contain the execution logs of the script, that were printed into stdout
- Using the get_attribute expression (see :ref:`expression` -> get_attribute),
+ Using the get_attribute expression (see :ref:`expression` -> get_attribute),
this attribute can be retrieve to be provided as workflow output (see :ref:`workflow`).
**Params:**
- The `command` field need to reference the path from the Scripts folder of the
+ The `command` field need to reference the path from the Scripts folder of the
scripts to execute, e.g. Scripts/python/Bob.py
- The `packages` field allow to provide a list of **PIP package** to install in the target environment,
+ The `packages` field allow to provide a list of **PIP package** to install in the target environment,
or a requirements.txt file. Also, it supports **Ansible role**.
- If **requirements.txt** is specified, then it should be **provided** as
+ If **requirements.txt** is specified, then it should be **provided** as
part of the **Environment** folder of the CBA.
.. code-block:: json
:caption: **Example**
"packages": [
- {
- "type": "pip",
- "package": [
+ {
+ "type": "pip",
+ "package": [
"requirements.txt"
- ]
- },
- {
- "type": "ansible_galaxy",
- "package": [
+ ]
+ },
+ {
+ "type": "ansible_galaxy",
+ "package": [
"juniper.junos"
- ]
- }
+ ]
+ }
]
- The `argument-properties` allows to specified input argument to the script to execute. They should be
- expressed in a DSL, and they will be ordered as specified.
+ The `argument-properties` allows to specified input argument to the script to execute. They should be
+ expressed in a DSL, and they will be ordered as specified.
.. code-block:: json
- :caption: **Example**
+ :caption: **Example**
"ansible-argument-properties": {
- "arg0": "-i",
- "arg1": "Scripts/ansible/inventory.yaml",
- "arg2": "--extra-vars",
- "arg3": {
- "get_attribute": [
+ "arg0": "-i",
+ "arg1": "Scripts/ansible/inventory.yaml",
+ "arg2": "--extra-vars",
+ "arg3": {
+ "get_attribute": [
"resolve-ansible-vars",
"",
"assignment-params",
"ansible-vars"
- ]
- }
- }
+ ]
+ }
}
- The `dynamic-properties` can be anything that needs to be passed to the
- script that couldn't be passed as an argument, such as JSON object, etc... If used, they will be passed
+ The `dynamic-properties` can be anything that needs to be passed to the
+ script that couldn't be passed as an argument, such as JSON object, etc... If used, they will be passed
in as the last argument of the Python script.
`Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/node_type/component-remote-python-executor.json>`_
is the definition
.. code-block:: json
- :caption: **component-remote-script-executor**
+ :caption: **component-remote-script-executor**
{
- "description": "This is Remote Python Execution Component.",
- "version": "1.0.0",
- "attributes": {
+ "description": "This is Remote Python Execution Component.",
+ "version": "1.0.0",
+ "attributes": {
"prepare-environment-logs": {
- "required": false,
- "type": "string"
+ "required": false,
+ "type": "string"
},
"execute-command-logs": {
- "required": false,
- "type": "list",
- "entry_schema": {
- "type": "string"
- }
+ "required": false,
+ "type": "list",
+ "entry_schema": {
+ "type": "string"
+ }
},
"response-data": {
- "required": false,
- "type": "json"
+ "required": false,
+ "type": "json"
}
- },
- "capabilities": {
+ },
+ "capabilities": {
"component-node": {
- "type": "tosca.capabilities.Node"
+ "type": "tosca.capabilities.Node"
}
- },
- "interfaces": {
+ },
+ "interfaces": {
"ComponentRemotePythonExecutor": {
- "operations": {
- "process": {
+ "operations": {
+ "process": {
"inputs": {
- "endpoint-selector": {
- "description": "Remote Container or Server selector name.",
- "required": false,
- "type": "string",
- "default": "remote-python"
- },
- "dynamic-properties": {
- "description": "Dynamic Json Content or DSL Json reference.",
- "required": false,
- "type": "json"
- },
- "argument-properties": {
- "description": "Argument Json Content or DSL Json reference.",
- "required": false,
- "type": "json"
- },
- "command": {
- "description": "Command to execute.",
- "required": true,
- "type": "string"
- },
- "packages": {
- "description": "Packages to install based on type.",
- "required": false,
- "type" : "list",
- "entry_schema" : {
+ "endpoint-selector": {
+ "description": "Remote Container or Server selector name.",
+ "required": false,
+ "type": "string",
+ "default": "remote-python"
+ },
+ "dynamic-properties": {
+ "description": "Dynamic Json Content or DSL Json reference.",
+ "required": false,
+ "type": "json"
+ },
+ "argument-properties": {
+ "description": "Argument Json Content or DSL Json reference.",
+ "required": false,
+ "type": "json"
+ },
+ "command": {
+ "description": "Command to execute.",
+ "required": true,
+ "type": "string"
+ },
+ "packages": {
+ "description": "Packages to install based on type.",
+ "required": false,
+ "type" : "list",
+ "entry_schema" : {
"type" : "dt-system-packages"
- }
- }
+ }
+ }
}
- }
- }
+ }
+ }
}
- },
- "derived_from": "tosca.nodes.Component"
+ },
+ "derived_from": "tosca.nodes.Component"
}
.. tab:: remote-ansible-executor
@@ -428,71 +427,71 @@ listed in the other section.
.. code-block:: json
:caption: **component-remote-script-executor**
- {
- "description": "This is Remote Ansible Playbook (AWX) Execution Component.",
- "version": "1.0.0",
- "attributes": {
- "ansible-command-status": {
+ {
+ "description": "This is Remote Ansible Playbook (AWX) Execution Component.",
+ "version": "1.0.0",
+ "attributes": {
+ "ansible-command-status": {
"required": true,
"type": "string"
- },
- "ansible-command-logs": {
+ },
+ "ansible-command-logs": {
"required": true,
"type": "string"
- }
- },
- "capabilities": {
- "component-node": {
+ }
+ },
+ "capabilities": {
+ "component-node": {
"type": "tosca.capabilities.Node"
- }
- },
- "interfaces": {
- "ComponentRemoteAnsibleExecutor": {
+ }
+ },
+ "interfaces": {
+ "ComponentRemoteAnsibleExecutor": {
"operations": {
- "process": {
- "inputs": {
+ "process": {
+ "inputs": {
"job-template-name": {
- "description": "Primary key or name of the job template to launch new job.",
- "required": true,
- "type": "string"
+ "description": "Primary key or name of the job template to launch new job.",
+ "required": true,
+ "type": "string"
},
"limit": {
- "description": "Specify host limit for job template to run.",
- "required": false,
- "type": "string"
+ "description": "Specify host limit for job template to run.",
+ "required": false,
+ "type": "string"
},
"inventory": {
- "description": "Specify inventory for job template to run.",
- "required": false,
- "type": "string"
+ "description": "Specify inventory for job template to run.",
+ "required": false,
+ "type": "string"
},
- "extra-vars" : {
- "required" : false,
- "type" : "json",
- "description": "json formatted text that contains extra variables to pass on."
+ "extra-vars": {
+ "required": false,
+ "type": "json",
+ "description": "json formatted text that contains extra variables to pass on."
},
"tags": {
- "description": "Specify tagged actions in the playbook to run.",
- "required": false,
- "type": "string"
+ "description": "Specify tagged actions in the playbook to run.",
+ "required": false,
+ "type": "string"
},
"skip-tags": {
- "description": "Specify tagged actions in the playbook to omit.",
- "required": false,
- "type": "string"
+ "description": "Specify tagged actions in the playbook to omit.",
+ "required": false,
+ "type": "string"
},
"endpoint-selector": {
- "description": "Remote AWX Server selector name.",
- "required": true,
- "type": "string"
+ "description": "Remote AWX Server selector name.",
+ "required": true,
+ "type": "string"
}
- }
- }
+ }
+ }
}
- }
- },
- "derived_from": "tosca.nodes.Component"
- }
+ }
+ },
+ "derived_from": "tosca.nodes.Component"
+ }
.. tab:: Source
@@ -502,38 +501,39 @@ listed in the other section.
Defines the **contract** to resolve a resource.
- `Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/node_type/tosca.nodes.ResourceSource.json>`_
+ `Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/node_type/tosca.nodes.ResourceSource.json>`_
is the root component TOSCA node type from which other node type will derive:
.. code-block::
:caption: **tosca.nodes.Component**
{
- "description": "TOSCA base type for Resource Sources",
- "version": "1.0.0",
- "derived_from": "tosca.nodes.Root"
+ "description": "TOSCA base type for Resource Sources",
+ "version": "1.0.0",
+ "derived_from": "tosca.nodes.Root"
}
**Bellow is a list of supported sources**
- .. tabs::
+ .. tabs::
+
.. tab:: input
**Input:**
Expects the **value to be provided as input** to the request.
- `Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/node_type/source-input.json>`_
+ `Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/node_type/source-input.json>`_
is the Definition
- .. code-block::
+ .. code-block::
:caption: **source-input**
{
- "description": "This is Input Resource Source Node Type",
- "version": "1.0.0",
- "properties": {},
- "derived_from": "tosca.nodes.ResourceSource"
+ "description": "This is Input Resource Source Node Type",
+ "version": "1.0.0",
+ "properties": {},
+ "derived_from": "tosca.nodes.ResourceSource"
}
.. tab:: default
@@ -542,17 +542,17 @@ listed in the other section.
Expects the **value to be defaulted** in the model itself.
- `Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/node_type/source-default.json>`_
+ `Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/node_type/source-default.json>`_
is the Definition
.. code-block:: json
:caption: **source-default**
{
- "description": "This is Default Resource Source Node Type",
- "version": "1.0.0",
- "properties": {},
- "derived_from": "tosca.nodes.ResourceSource"
+ "description": "This is Default Resource Source Node Type",
+ "version": "1.0.0",
+ "properties": {},
+ "derived_from": "tosca.nodes.ResourceSource"
}
.. tab:: rest
@@ -561,7 +561,7 @@ listed in the other section.
Expects the **URI along with the VERB and the payload**, if needed.
- CDS is currently deployed along the side of SDNC, hence the **default** rest
+ CDS is currently deployed along the side of SDNC, hence the **default** rest
**connection** provided by the framework is to **SDNC MDSAL**.
.. list-table::
@@ -592,105 +592,107 @@ listed in the other section.
* - expression-type
- Path expression type - default value is JSON_PATH
- Optional
-
- `Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/node_type/source-rest.json>`_
+
+ `Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/node_type/source-rest.json>`_
is the definition:
.. code-block:: json
:caption: **source-rest**
- {
- "description": "This is Rest Resource Source Node Type",
- "version": "1.0.0",
- "properties": {
- "type": {
- "required": false,
- "type": "string",
- "default": "JSON",
- "constraints": [
- {
- "valid_values": [
- "JSON"
- ]
- }
- ]
- },
- "verb": {
- "required": false,
- "type": "string",
- "default": "GET",
- "constraints": [
- {
- "valid_values": [
- "GET", "POST", "DELETE", "PUT"
- ]
- }
- ]
- },
- "payload": {
- "required": false,
- "type": "string",
- "default": ""
- },
- "endpoint-selector": {
- "required": false,
- "type": "string"
- },
- "url-path": {
- "required": true,
- "type": "string"
- },
- "path": {
- "required": true,
- "type": "string"
- },
- "expression-type": {
- "required": false,
- "type": "string",
- "default": "JSON_PATH",
- "constraints": [
- {
- "valid_values": [
- "JSON_PATH",
- "JSON_POINTER"
- ]
- }
- ]
- },
- "input-key-mapping": {
- "required": false,
- "type": "map",
- "entry_schema": {
- "type": "string"
- }
- },
- "output-key-mapping": {
- "required": false,
- "type": "map",
- "entry_schema": {
- "type": "string"
- }
+ {
+ "description": "This is Rest Resource Source Node Type",
+ "version": "1.0.0",
+ "properties": {
+ "type": {
+ "required": false,
+ "type": "string",
+ "default": "JSON",
+ "constraints": [
+ {
+ "valid_values": [
+ "JSON"
+ ]
+ }
+ ]
+ },
+ "verb": {
+ "required": false,
+ "type": "string",
+ "default": "GET",
+ "constraints": [
+ {
+ "valid_values": [
+ "GET",
+ "POST",
+ "DELETE",
+ "PUT"
+ ]
+ }
+ ]
+ },
+ "payload": {
+ "required": false,
+ "type": "string",
+ "default": ""
+ },
+ "endpoint-selector": {
+ "required": false,
+ "type": "string"
+ },
+ "url-path": {
+ "required": true,
+ "type": "string"
+ },
+ "path": {
+ "required": true,
+ "type": "string"
+ },
+ "expression-type": {
+ "required": false,
+ "type": "string",
+ "default": "JSON_PATH",
+ "constraints": [
+ {
+ "valid_values": [
+ "JSON_PATH",
+ "JSON_POINTER"
+ ]
+ }
+ ]
+ },
+ "input-key-mapping": {
+ "required": false,
+ "type": "map",
+ "entry_schema": {
+ "type": "string"
+ }
+ },
+ "output-key-mapping": {
+ "required": false,
+ "type": "map",
+ "entry_schema": {
+ "type": "string"
+ }
+ },
+ "key-dependencies": {
+ "required": true,
+ "type": "list",
+ "entry_schema": {
+ "type": "string"
+ }
+ }
},
- "key-dependencies": {
- "required": true,
- "type": "list",
- "entry_schema": {
- "type": "string"
- }
- }
- },
- "derived_from": "tosca.nodes.ResourceSource"
- }
-
+ "derived_from": "tosca.nodes.ResourceSource"
+ }
.. tab:: sql
**SQL**
- Expects the **SQL query** to be modeled; that SQL query can be parameterized,
- and the parameters be other resources resolved through other means.
+ Expects the **SQL query** to be modeled; that SQL query can be parameterized,
+ and the parameters be other resources resolved through other means.
If that's the case, this data dictionary definition will have to define ``key-dependencies`` along with ``input-key-mapping``.
- CDS is currently deployed along the side of SDNC, hence the **primary** database
+ CDS is currently deployed along the side of SDNC, hence the **primary** database
**connection** provided by the framework is to **SDNC database**.
.. list-table::
@@ -709,60 +711,60 @@ listed in the other section.
- Statement to execute
- Mandatory
-
- `Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/node_type/source-processor-db.json>`_
+
+ `Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/node_type/source-processor-db.json>`_
is the definition:
.. code-block:: json
:caption: **source-db**
- {
- "description": "This is Database Resource Source Node Type",
- "version": "1.0.0",
- "properties": {
- "type": {
+ {
+ "description": "This is Database Resource Source Node Type",
+ "version": "1.0.0",
+ "properties": {
+ "type": {
"required": true,
"type": "string",
"constraints": [
- {
- "valid_values": [
+ {
+ "valid_values": [
"SQL"
- ]
- }
+ ]
+ }
]
- },
- "endpoint-selector": {
+ },
+ "endpoint-selector": {
"required": false,
"type": "string"
- },
- "query": {
+ },
+ "query": {
"required": true,
"type": "string"
- },
- "input-key-mapping": {
+ },
+ "input-key-mapping": {
"required": false,
"type": "map",
"entry_schema": {
- "type": "string"
+ "type": "string"
}
- },
- "output-key-mapping": {
+ },
+ "output-key-mapping": {
"required": false,
"type": "map",
"entry_schema": {
- "type": "string"
+ "type": "string"
}
- },
- "key-dependencies": {
+ },
+ "key-dependencies": {
"required": true,
"type": "list",
"entry_schema": {
- "type": "string"
+ "type": "string"
}
- }
- },
- "derived_from": "tosca.nodes.ResourceSource"
- }
+ }
+ },
+ "derived_from": "tosca.nodes.ResourceSource"
+ }
.. tab:: capability
@@ -777,53 +779,53 @@ listed in the other section.
* - Property
- Description
- Scope
- * - script-type
+ * - script-type
- The type of the script - default value is Koltin
- Optional
* - script-class-reference
- The name of the class to use to create an instance of the script
- Mandatory
- `Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/node_type/source-capability.json>`_
- is the definition:
+ `Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/node_type/source-capability.json>`_
+ is the definition:
.. code-block:: json
- :caption: **source-capability**
+ :caption: **source-capability**
- {
- "description": "This is Component Resource Source Node Type",
- "version": "1.0.0",
- "properties": {
- "script-type": {
+ {
+ "description": "This is Component Resource Source Node Type",
+ "version": "1.0.0",
+ "properties": {
+ "script-type": {
"required": true,
"type": "string",
"default": "kotlin",
"constraints": [
- {
- "valid_values": [
+ {
+ "valid_values": [
"internal",
"kotlin",
"jython"
- ]
- }
+ ]
+ }
]
- },
- "script-class-reference": {
+ },
+ "script-class-reference": {
"description": "Capability reference name for internal and kotlin, for jython script file path",
"required": true,
"type": "string"
- },
- "key-dependencies": {
+ },
+ "key-dependencies": {
"description": "Resource Resolution dependency dictionary names.",
"required": true,
"type": "list",
"entry_schema": {
- "type": "string"
+ "type": "string"
}
- }
- },
- "derived_from": "tosca.nodes.ResourceSource"
- }
+ }
+ },
+ "derived_from": "tosca.nodes.ResourceSource"
+ }
.. tab:: Other
@@ -844,57 +846,65 @@ listed in the other section.
* - Property
- Description
- Scope
- * - dependency-node-templates
+ * - dependency-node-templates
- The node template the workflow depends on
- Required
- `Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/node_type/dg-generic.json>`_
- is the definition:
+ `Here <https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/definition-type/starter-type/node_type/dg-generic.json>`_
+ is the definition:
.. code-block:: json
:caption: **dg-generic**
- {
- "description": "This is Generic Directed Graph Type",
- "version": "1.0.0",
- "properties": {
- "content": {
- "required": true,
- "type": "string"
+ {
+ "description": "This is Generic Directed Graph Type",
+ "version": "1.0.0",
+ "properties": {
+ "content": {
+ "required": true,
+ "type": "string"
+ },
+ "dependency-node-templates": {
+ "required": true,
+ "description": "Dependent Step Components NodeTemplate name.",
+ "type": "list",
+ "entry_schema": {
+ "type": "string"
+ }
+ }
},
- "dependency-node-templates": {
- "required": true,
- "description": "Dependent Step Components NodeTemplate name.",
- "type": "list",
- "entry_schema": {
- "type": "string"
- }
- }
- },
- "derived_from": "tosca.nodes.DG"
- }
+ "derived_from": "tosca.nodes.DG"
+ }
- A node_template of this type always provide one artifact, of type artifact-directed-graph,
+ A node_template of this type always provide one artifact, of type artifact-directed-graph,
which will be located under the Plans/ folder within the CBA.
.. code-block:: json
:caption: **node_template example**
- "config-deploy-process" : {
- "type" : "dg-generic",
- "properties" : {
- "content" : {
- "get_artifact" : [ "SELF", "dg-config-deploy-process" ]
- },
- "dependency-node-templates" : [ "nf-account-collection", "execute" ]
- },
- "artifacts" : {
- "dg-config-deploy-process" : {
- "type" : "artifact-directed-graph",
- "file" : "Plans/CONFIG_ConfigDeploy.xml"
+ {
+ "config-deploy-process": {
+ "type": "dg-generic",
+ "properties": {
+ "content": {
+ "get_artifact": [
+ "SELF",
+ "dg-config-deploy-process"
+ ]
+ },
+ "dependency-node-templates": [
+ "nf-account-collection",
+ "execute"
+ ]
+ },
+ "artifacts": {
+ "dg-config-deploy-process": {
+ "type": "artifact-directed-graph",
+ "file": "Plans/CONFIG_ConfigDeploy.xml"
+ }
+ }
}
- }
- }
+ }
In the DG bellow, the execute node refers to the node_template.
@@ -907,24 +917,24 @@ listed in the other section.
xsi:schemaLocation='http://www.onap.org/sdnc/svclogic ./svclogic.xsd' module='CONFIG' version='1.0.0'>
<method rpc='ConfigDeploy' mode='sync'>
<block atomic="true">
- <execute plugin="nf-account-collection" method="process">
- <outcome value='failure'>
- <return status="failure">
- </return>
- </outcome>
- <outcome value='success'>
- <execute plugin="execute" method="process">
- <outcome value='failure'>
- <return status="failure">
- </return>
- </outcome>
- <outcome value='success'>
- <return status='success'>
- </return>
- </outcome>
- </execute>
- </outcome>
- </execute>
+ <execute plugin="nf-account-collection" method="process">
+ <outcome value='failure'>
+ <return status="failure">
+ </return>
+ </outcome>
+ <outcome value='success'>
+ <execute plugin="execute" method="process">
+ <outcome value='failure'>
+ <return status="failure">
+ </return>
+ </outcome>
+ <outcome value='success'>
+ <return status='success'>
+ </return>
+ </outcome>
+ </execute>
+ </outcome>
+ </execute>
</block>
</method>
</service-logic>
@@ -945,7 +955,7 @@ listed in the other section.
"version": "1.0.0",
"derived_from": "tosca.nodes.Root"
}
-
+
**vnf-netconf-device**
Represents the VNF information to **establish** a **NETCONF communication**.
@@ -997,36 +1007,3 @@ listed in the other section.
},
"derived_from": "tosca.nodes.Vnf"
}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/docs/modelingconcepts/scripts.rst b/docs/modelingconcepts/scripts.rst
index db79496c2..39330f166 100644
--- a/docs/modelingconcepts/scripts.rst
+++ b/docs/modelingconcepts/scripts.rst
@@ -4,7 +4,7 @@
.. Copyright (C) 2020 Deutsche Telekom AG.
Scripts
--------------
+-------
Library
+++++++++++++++++
@@ -12,7 +12,7 @@ Library
NetconfClient
+++++++++++++++++
-In order to facilitate NETCONF interaction within scripts, a python NetconfClient binded to our Kotlin implementation is made available.
+In order to facilitate NETCONF interaction within scripts, a python NetconfClient binded to our Kotlin implementation is made available.
This NetconfClient can be used when using the component-netconf-executor.
The client can be find here: https://github.com/onap/ccsdk-cds/blob/master/components/scripts/python/ccsdk_netconf/netconfclient.py
@@ -20,8 +20,8 @@ The client can be find here: https://github.com/onap/ccsdk-cds/blob/master/compo
ResolutionHelper
+++++++++++++++++
-When executing a component executor script, designer might want to perform
+When executing a component executor script, designer might want to perform
resource resolution along with template meshing directly from the script itself.
-The helper can be find here:
+The helper can be find here:
https://github.com/onap/ccsdk-cds/blob/master/components/scripts/python/ccsdk_netconf/common.py \ No newline at end of file
diff --git a/docs/modelingconcepts/southbound-interfaces.rst b/docs/modelingconcepts/southbound-interfaces.rst
index 865e89620..d2bde92a8 100644
--- a/docs/modelingconcepts/southbound-interfaces.rst
+++ b/docs/modelingconcepts/southbound-interfaces.rst
@@ -4,11 +4,11 @@
.. Copyright (C) 2020 Deutsche Telekom AG.
Southbound Interfaces
--------------------------
+---------------------
-CDS comes with native python 3.6 support and Ansible AWX (Ansible Tower):
-idea is Network Ops are familiar with Python and/or Ansible, and our goal is not to dictate the SBI to use for
-their operations. Ansible and Python provide already many, and well adopted,
+CDS comes with native python 3.6 support and Ansible AWX (Ansible Tower):
+idea is Network Ops are familiar with Python and/or Ansible, and our goal is not to dictate the SBI to use for
+their operations. Ansible and Python provide already many, and well adopted,
SBI libraries, hence they could be utilized as needed.
CDS also provide native support for the following libraries:
@@ -19,5 +19,5 @@ CDS also provide native support for the following libraries:
* SSH
* gRPC (hence gNMI / gNOI should be supported)
-CDS also has extensible REST support, meaning any RESTful interface used for network interaction can be used,
+CDS also has extensible REST support, meaning any RESTful interface used for network interaction can be used,
such as external VNFM or EMS. \ No newline at end of file
diff --git a/docs/modelingconcepts/template.rst b/docs/modelingconcepts/template.rst
index d8d35189a..75fe56a43 100644
--- a/docs/modelingconcepts/template.rst
+++ b/docs/modelingconcepts/template.rst
@@ -6,14 +6,14 @@
.. _template:
Template
------------
+--------
-A template is an **artifact**, and uses artifact-mapping-resource (see :ref:`artifact_type` -> Mapping)
+A template is an **artifact**, and uses artifact-mapping-resource (see :ref:`artifact_type` -> Mapping)
and artifact-template-velocity (see :ref:`artifact_type` -> Velocity).
A template is **parameterized** and each parameter must be defined in a corresponding **mapping file**.
-In order to know which mapping correlates to which template, the file name must start with an ``artifact-prefix``,
+In order to know which mapping correlates to which template, the file name must start with an ``artifact-prefix``,
serving as identifier to the overall template + mapping.
The **requirement** is as follows:
diff --git a/docs/modelingconcepts/test.rst b/docs/modelingconcepts/test.rst
index ba806354e..53bbc1adf 100644
--- a/docs/modelingconcepts/test.rst
+++ b/docs/modelingconcepts/test.rst
@@ -4,15 +4,15 @@
.. Copyright (C) 2020 Deutsche Telekom AG.
Tests
---------
+-----
-The **tests** folder contains the **uat.yaml** file for execution the cba actions for sunny day and rainy day
-scenario using mock data. The process to generate the uat file is documented TBD. The file can be dragged
-and drop to the Tests folder after the test for all actions are executed.
+The **tests** folder contains the **uat.yaml** file for execution the cba actions for sunny day and rainy day
+scenario using mock data. The process to generate the uat file is documented TBD. The file can be dragged
+and drop to the Tests folder after the test for all actions are executed.
-NOTE: You need to activate the "uat" Spring Boot profile in order to enable the spy/verify endpoints.
-They are disabled by default because the mocks created at runtime can potentially cause collateral problems in production.
-You can either pass an option to JVM (``-Dspring.profiles.active=uat``) or set and export an
+NOTE: You need to activate the "uat" Spring Boot profile in order to enable the spy/verify endpoints.
+They are disabled by default because the mocks created at runtime can potentially cause collateral problems in production.
+You can either pass an option to JVM (``-Dspring.profiles.active=uat``) or set and export an
environment variable (``export spring_profiles_active=uat``).
A quick outline of the UAT generation process follows:
@@ -20,21 +20,21 @@ A quick outline of the UAT generation process follows:
1. Create a minimum :file:`uat.yaml` containing only the NB requests to be sent to the BlueprintsProcessor (BPP) service;
2. Submit the blueprint CBA and this draft :file:`uat.yaml` to BPP in a single HTTP POST call:
- ``curl -u ccsdkapps:ccsdkapps -F cba=@<path to your CBA file> -F uat=@<path to the
+ ``curl -u ccsdkapps:ccsdkapps -F cba=@<path to your CBA file> -F uat=@<path to the
draft uat.yaml> http://localhost:8080/api/v1/uat/spy``
3. If your environment is properly setup, at the end this service will generate the complete :file:`uat.yaml`;
4. Revise the generate file, eventually removing superfluous message fields;
5. Include this file in your CBA under :file:`Tests/uat.yaml`;
-6. Submit the candidate CBA + UAT to be validated by BPP, that now will create runtime mocks to simulate
+6. Submit the candidate CBA + UAT to be validated by BPP, that now will create runtime mocks to simulate
all SB collaborators, by running:
``$ curl -u ccsdkapps:ccsdkapps -F cba=@<path to your CBA file> http://localhost:8080/api/v1/uat/verify``
-7. Once validated, your CBA enhanced with its corresponding UAT is eligible
+7. Once validated, your CBA enhanced with its corresponding UAT is eligible
to be integrated into the CDS project, under the folder :file:`components/model-catalog/blueprint-model/uat-blueprints`.
-Reference link for sample generated uat.yaml file for pnf plug & play use case:
+Reference link for sample generated uat.yaml file for pnf plug & play use case:
`uat.yaml file <https://gerrit.onap.org/r/gitweb?p=ccsdk/cds.git;a=tree;f=components/model-catalog/blueprint-model/uat-blueprints/pnf_config/Tests;h=230d506720c4a1066784c1fe9e0ba0206bbb13cf;hb=refs/heads/master>`_.
-As UAT is part of unit testing, it runs in jenkins job
-`ccsdk-cds-master-verify-java <https://jenkins.onap.org/job/ccsdk-cds-master-verify-java/>`_
+As UAT is part of unit testing, it runs in jenkins job
+`ccsdk-cds-master-verify-java <https://jenkins.onap.org/job/ccsdk-cds-master-verify-java/>`_
whenever a new commit/patch pushed on gerrit in ccsdk/cds repo. \ No newline at end of file
diff --git a/docs/modelingconcepts/tosca-meta.rst b/docs/modelingconcepts/tosca-meta.rst
index d27277016..938af315a 100644
--- a/docs/modelingconcepts/tosca-meta.rst
+++ b/docs/modelingconcepts/tosca-meta.rst
@@ -4,7 +4,7 @@
.. Copyright (C) 2020 Deutsche Telekom AG.
Tosca Meta
-------------
+----------
Tosca meta file captures the model entities that compose the cba package name, version, type and searchable tags.
@@ -41,23 +41,20 @@ Tosca meta file captures the model entities that compose the cba package name, v
- Required
- String
- | The attribute that holds the blueprint version
- |
- | X.Y.Z
- |
+ | **X.Y.Z**
| X=Major version
| Y=Minor Version
| Z=Revision Version
- |
- | X=Ex. 1.0.0
+ | X=Ex. 1.0.0
* - Template-Type
- Required
- String
- | The attribute that holds the blueprint package types.
| Valid Options:
* "DEFAULT" – .JSON file consistent of tosca based cba package that describes the package intent.
- * "KOTLIN_DSL" – .KT file consistent of tosca based cba package that describes the package intent
- composed using Domain Specific Language (DSL).
- * "GENERIC_SCRIPT" – Script file consistent of NONE tosca based cba package that describes the package intent
+ * "KOTLIN_DSL" – .KT file consistent of tosca based cba package that describes the package intent
+ composed using Domain Specific Language (DSL).
+ * "GENERIC_SCRIPT" – Script file consistent of NONE tosca based cba package that describes the package intent
using DSL Language.
| If not specified in the tosca.meta file the default is "DEFAULT"
* - Template-Tags
@@ -69,12 +66,12 @@ Tosca meta file captures the model entities that compose the cba package name, v
**Default Template Type**
-https://gerrit.onap.org/r/gitweb?p=ccsdk/cds.git;a=blob;f=components/model-catalog/blueprint-model/test-blueprint/capability_cli/TOSCA-Metadata/TOSCA.meta;hb=refs/heads/master
+https://git.onap.org/ccsdk/cds/tree/components/model-catalog/blueprint-model/test-blueprint/capability_cli/TOSCA-Metadata/TOSCA.meta
**KOTLIN_DSL Template Type**
-https://gerrit.onap.org/r/gitweb?p=ccsdk/cds.git;a=blob;f=components/model-catalog/blueprint-model/test-blueprint/resource-audit/TOSCA-Metadata/TOSCA.meta;hb=refs/heads/master
+https://git.onap.org/ccsdk/cds/tree/components/model-catalog/blueprint-model/test-blueprint/resource-audit/TOSCA-Metadata/TOSCA.meta
**GENERIC_SCRIPT Template Type**
-https://gerrit.onap.org/r/gitweb?p=ccsdk/cds.git;a=tree;f=ms/py-executor/test/resources/sample-cba/1.0.0;hb=refs/heads/master \ No newline at end of file
+https://git.onap.org/ccsdk/cds/tree/components/model-catalog/blueprint-model/test-blueprint/capability_python/TOSCA-Metadata/TOSCA.meta \ No newline at end of file
diff --git a/docs/modelingconcepts/workflow.rst b/docs/modelingconcepts/workflow.rst
index 8216819ac..9b9bd5220 100644
--- a/docs/modelingconcepts/workflow.rst
+++ b/docs/modelingconcepts/workflow.rst
@@ -6,19 +6,19 @@
.. _workflow:
Workflow
----------
+--------
.. note::
**Workflow Scope within CDS Framework**
- The workflow is within the scope of the micro provisioning and configuration
- management in **controller domain** and does NOT account for the MACRO service orchestration workflow which is covered by the SO Project.
+ The workflow is within the scope of the micro provisioning and configuration
+ management in **controller domain** and does NOT account for the MACRO service orchestration workflow which is covered by the SO Project.
-A workflow defines an overall action to be taken on the service, hence is an
+A workflow defines an overall action to be taken on the service, hence is an
entry-point for the run-time execution of the :ref:`CBA Package <cba>`.
-A workflow also defines **inputs** and **outputs** that will defined the **payload contract**
+A workflow also defines **inputs** and **outputs** that will defined the **payload contract**
of the **request** and **response** (see :ref:`Dynamic API`)
A workflow can be **composed** of one or multiple **sub-actions** to execute.
@@ -32,10 +32,10 @@ Single action
The workflow is directly backed by a component (see :ref:`node_type` -> Component).
-In the example bellow, the target of the workflow's steps resource-assignment is ``resource-assignment``
+In the example bellow, the target of the workflow's steps resource-assignment is ``resource-assignment``
which actually is the name of the ``node_template`` defined after, of type ``component-resource-resolution``.
-`Link to example
+`Link to example
<https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/blueprint-model/test-blueprint/golden/Definitions/golden-blueprint.json#L40-L71>`_
@@ -43,168 +43,170 @@ which actually is the name of the ``node_template`` defined after, of type ``com
:caption: **Example**
. . .
- "topology_template": {
- "workflows": {
- "resource-assignment": {
- "steps": {
- "resource-assignment": {
- "description": "Resource Assign Workflow",
- "target": "resource-assignment"
- ]
+ "topology_template": {
+ "workflows": {
+ "resource-assignment": {
+ "steps": {
+ "resource-assignment": {
+ "description": "Resource Assign Workflow",
+ "target": "resource-assignment"
+ }
}
- },
- "inputs": {
+ },
+ "inputs": {
"resource-assignment-properties": {
- "description": "Dynamic PropertyDefinition for workflow(resource-assignment).",
- "required": true,
- "type": "dt-resource-assignment-properties"
+ "description": "Dynamic PropertyDefinition for workflow(resource-assignment).",
+ "required": true,
+ "type": "dt-resource-assignment-properties"
}
- },
- "outputs": {
+ },
+ "outputs": {
"meshed-template": {
- "type": "json",
- "value": {
- "get_attribute": [
+ "type": "json",
+ "value": {
+ "get_attribute": [
"resource-assignment",
"assignment-params"
- ]
- }
+ ]
+ }
}
- }
- },
- "node_templates": {
- "resource-assignment": {
- "type": "component-resource-resolution",
- "interfaces": {
- "ResourceResolutionComponent": {
- "operations": {
- "process": {
- "inputs": {
- "artifact-prefix-names": [
- "vf-module-1"
- ]
+ }
+ },
+ "node_templates": {
+ "resource-assignment": {
+ "type": "component-resource-resolution",
+ "interfaces": {
+ "ResourceResolutionComponent": {
+ "operations": {
+ "process": {
+ "inputs": {
+ "artifact-prefix-names": [
+ "vf-module-1"
+ ]
+ }
}
- }
- }
- }
- },
- "artifacts": {
- "vf-module-1-template": {
- "type": "artifact-template-velocity",
- "file": "Templates/vf-module-1-template.vtl"
+ }
+ }
},
- "vf-module-1-mapping": {
- "type": "artifact-mapping-resource",
- "file": "Templates/vf-module-1-mapping.json"
+ "artifacts": {
+ "vf-module-1-template": {
+ "type": "artifact-template-velocity",
+ "file": "Templates/vf-module-1-template.vtl"
+ },
+ "vf-module-1-mapping": {
+ "type": "artifact-mapping-resource",
+ "file": "Templates/vf-module-1-mapping.json"
+ }
}
- }
- }
+ }
+ }
}
- . . .
+ . . .
.. _workflow_multiple_actions:
Multiple sub-actions
**********************
-The workflow is backed by a Directed Graph engine, dg-generic (see :ref:`node_type` -> DG,
+The workflow is backed by a Directed Graph engine, dg-generic (see :ref:`node_type` -> DG,
and is an **imperative** workflow.
-A DG used as workflow for CDS is composed of multiple execute nodes; each individual
+A DG used as workflow for CDS is composed of multiple execute nodes; each individual
execute node refers to an modelled Component (see :ref:`node_type` -> Component) instance.
-In the example above, you can see the target of the workflow's steps execute-script is
+In the example above, you can see the target of the workflow's steps execute-script is
``execute-remote-ansible-process``, which is a node_template of type ``dg_generic``
-`Link of example
-<https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/blueprint-model/test-blueprint/remote_scripts/Definitions/remote_scripts.json#L184-L204>`_
+`Link of example
+<https://github.com/onap/ccsdk-cds/blob/master/components/model-catalog/blueprint-model/test-blueprint/remote_scripts/Definitions/remote_scripts.json#L184-L204>`_
.. code-block:: json
:caption: **workflow plan example**
- . . .
- "topology_template": {
+ . . .
+ "topology_template": {
"workflows": {
- "execute-remote-ansible": {
- "steps": {
+ "execute-remote-ansible": {
+ "steps": {
"execute-script": {
- "description": "Execute Remote Ansible Script",
- "target": "execute-remote-ansible-process"
- ]
+ "description": "Execute Remote Ansible Script",
+ "target": "execute-remote-ansible-process"
}
- },
- "inputs": {
- "ip": {
- "required": false,
- "type": "string"
- },
- "username": {
- "required": false,
- "type": "string"
- },
- "password": {
- "required": false,
- "type": "string"
- },
- "execute-remote-ansible-properties": {
- "description": "Dynamic PropertyDefinition for workflow(execute-remote-ansible).",
- "required": true,
- "type": "dt-execute-remote-ansible-properties"
+ }
+ },
+ "inputs": {
+ "ip": {
+ "required": false,
+ "type": "string"
+ },
+ "username": {
+ "required": false,
+ "type": "string"
+ },
+ "password": {
+ "required": false,
+ "type": "string"
+ },
+ "execute-remote-ansible-properties": {
+ "description": "Dynamic PropertyDefinition for workflow(execute-remote-ansible).",
+ "required": true,
+ "type": "dt-execute-remote-ansible-properties"
+ }
+ },
+ "outputs": {
+ "ansible-variable-resolution": {
+ "type": "json",
+ "value": {
+ "get_attribute": [
+ "resolve-ansible-vars",
+ "assignment-params"
+ ]
}
- },
- "outputs": {
- "ansible-variable-resolution": {
- "type": "json",
- "value": {
- "get_attribute": [
- "resolve-ansible-vars",
- "assignment-params"
- ]
- }
- },
- "prepare-environment-logs": {
- "type": "string",
- "value": {
- "get_attribute": [
- "execute-remote-ansible",
- "prepare-environment-logs"
- ]
- }
- },
- "execute-command-logs": {
- "type": "string",
- "value": {
- "get_attribute": [
- "execute-remote-ansible",
- "execute-command-logs"
- ]
- }
+ },
+ "prepare-environment-logs": {
+ "type": "string",
+ "value": {
+ "get_attribute": [
+ "execute-remote-ansible",
+ "prepare-environment-logs"
+ ]
+ }
+ },
+ "execute-command-logs": {
+ "type": "string",
+ "value": {
+ "get_attribute": [
+ "execute-remote-ansible",
+ "execute-command-logs"
+ ]
}
- }
- }
- },
- "node_templates": {
- "execute-remote-ansible-process": {
- "type": "dg-generic",
- "properties": {
- "content": {
- "get_artifact": [
- "SELF",
- "dg-execute-remote-ansible-process"
- ]
+ }
+ },
+ "node_templates": {
+ "execute-remote-ansible-process": {
+ "type": "dg-generic",
+ "properties": {
+ "content": {
+ "get_artifact": [
+ "SELF",
+ "dg-execute-remote-ansible-process"
+ ]
+ },
+ "dependency-node-templates": [
+ "resolve-ansible-vars",
+ "execute-remote-ansible"
+ ]
},
- "dependency-node-templates": [
- "resolve-ansible-vars",
- "execute-remote-ansible"
- ]
- },
- "artifacts": {
- "dg-execute-remote-ansible-process": {
- "type": "artifact-directed-graph",
- "file": "Plans/CONFIG_ExecAnsiblePlaybook.xml"
+ "artifacts": {
+ "dg-execute-remote-ansible-process": {
+ "type": "artifact-directed-graph",
+ "file": "Plans/CONFIG_ExecAnsiblePlaybook.xml"
+ }
}
- }
- }
+ }
+ }
+ }
+ }
Properties of a workflow
**************************
@@ -219,12 +221,12 @@ Properties of a workflow
- Defines the name of the action that can be triggered by external system
* - inputs
- | They are two types of inputs, the dynamic ones, and the static one.
- |
+ |
.. tabs::
-
+
.. tab:: static
-
+
Specified at workflow level
* can be inputs for the Component(s), see the inputs section of the component of interest.
@@ -233,8 +235,8 @@ Properties of a workflow
These will end up under ``${actionName}-request`` section of the payload (see Dynamic API)
.. tab:: dynamic
-
- Represent the resources defined as input (see :ref:`node_type` -> Source -> Input)
+
+ Represent the resources defined as input (see :ref:`node_type` -> Source -> Input)
within mapping definition files (see :ref:`artifact_type` -> Mapping).
The **enrichment process** will (see :ref:`enrichment`)
@@ -265,17 +267,17 @@ Properties of a workflow
- value resolvable using :ref:`expression` -> get_attribute
* - steps
- | Defines the actual step to execute as part of the workflow
- |
+ |
.. list-table::
:widths: 25 25 50
- :header-rows: 1
-
+ :header-rows: 1
+
* - step-name
- description
- target
* - name of the step
- step description
- - | a node_template implementing on of the supported Node Type (see :ref:`node_type` -> DG),
+ - | a node_template implementing on of the supported Node Type (see :ref:`node_type` -> DG),
either a Component or a DG
| (see :ref:`workflow_single_action` or :ref:`workflow_multiple_actions`)
@@ -284,39 +286,39 @@ Example:
.. code-block:: json
:caption: **workflow example**
- {
- "workflow": {
- "resource-assignment": { <- workflow-name
+ {
+ "workflow": {
+ "resource-assignment": { <- workflow-name
"inputs": {
- "vnf-id": { <- static inputs
- "required": true,
- "type": "string"
- },
- "resource-assignment-properties": { <- dynamic inputs
- "required": true,
- "type": "dt-resource-assignment-properties"
- }
+ "vnf-id": { <- static inputs
+ "required": true,
+ "type": "string"
+ },
+ "resource-assignment-properties": { <- dynamic inputs
+ "required": true,
+ "type": "dt-resource-assignment-properties"
+ }
},
"steps": {
- "call-resource-assignment": { <- step-name
- "description": "Resource Assignment Workflow",
- "target": "resource-assignment-process" <- node_template targeted by the step
- }
+ "call-resource-assignment": { <- step-name
+ "description": "Resource Assignment Workflow",
+ "target": "resource-assignment-process" <- node_template targeted by the step
+ }
},
"outputs": {
- "template-properties": { <- output
- "type": "json", <- complex type
- "value": {
+ "template-properties": { <- output
+ "type": "json", <- complex type
+ "value": {
"get_attribute": [ <- uses expression to retrieve attribute from context
- "resource-assignment",
- "assignment-params"
+ "resource-assignment",
+ "assignment-params"
]
- }
- }
+ }
+ }
}
- }
+ }
+ }
}
- }
`TOSCA definition <http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454203>`_