diff options
Diffstat (limited to 'docs/modelingconcepts')
| -rw-r--r-- | docs/modelingconcepts/artifact-type.rst | 88 | ||||
| -rw-r--r-- | docs/modelingconcepts/cba.rst | 49 | ||||
| -rw-r--r-- | docs/modelingconcepts/data-dictionary.rst | 50 | ||||
| -rw-r--r-- | docs/modelingconcepts/data-type.rst | 163 | ||||
| -rw-r--r-- | docs/modelingconcepts/dynamic-payload.rst | 72 | ||||
| -rw-r--r-- | docs/modelingconcepts/enrichment.rst | 16 | ||||
| -rw-r--r-- | docs/modelingconcepts/expression.rst | 48 | ||||
| -rw-r--r-- | docs/modelingconcepts/external-system.rst | 120 | ||||
| -rw-r--r-- | docs/modelingconcepts/flexible-plug-in.rst | 122 | ||||
| -rw-r--r-- | docs/modelingconcepts/index.rst (renamed from docs/modelingconcepts/overview.rst) | 6 | ||||
| -rw-r--r-- | docs/modelingconcepts/node-type.rst | 841 | ||||
| -rw-r--r-- | docs/modelingconcepts/scripts.rst | 8 | ||||
| -rw-r--r-- | docs/modelingconcepts/southbound-interfaces.rst | 10 | ||||
| -rw-r--r-- | docs/modelingconcepts/template.rst | 6 | ||||
| -rw-r--r-- | docs/modelingconcepts/test.rst | 26 | ||||
| -rw-r--r-- | docs/modelingconcepts/tosca-meta.rst | 21 | ||||
| -rw-r--r-- | docs/modelingconcepts/workflow.rst | 338 |
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>`_ |