summaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
Diffstat (limited to 'docs')
-rw-r--r--docs/datadictionary/index.rst6
-rw-r--r--docs/datadictionary/resourcedefinitioncodesnip.rst (renamed from docs/datadictionary/resourceDefinitionCode.rst)0
-rw-r--r--docs/datadictionary/resourcesource.rst21
-rw-r--r--docs/index.rst106
-rw-r--r--docs/microservices/bluePrintsProcessorMS.rst8
-rw-r--r--docs/microservices/controllerBlueprintStudioProcessorMS.rst13
-rw-r--r--docs/microservices/expression.rst45
-rw-r--r--docs/microservices/images/blueprintprocessor.jpg (renamed from docs/media/blueprintprocessor.jpg)bin47208 -> 47208 bytes
-rw-r--r--docs/microservices/workflow.rst73
9 files changed, 207 insertions, 65 deletions
diff --git a/docs/datadictionary/index.rst b/docs/datadictionary/index.rst
index 0d87158d9..3ac8587ee 100644
--- a/docs/datadictionary/index.rst
+++ b/docs/datadictionary/index.rst
@@ -40,7 +40,7 @@ Here is how input-key-mapping, output-key-mapping and key-dependencies can be us
.. toctree::
:maxdepth: 1
-resourceDefintionCode
+ resourcedefinitioncodesnip
Resource source:
@@ -61,10 +61,10 @@ Also please click below for resource source available details
.. _Resource: https://wiki.onap.org/display/DW/Modeling+Concepts#ModelingConcepts-NodeResourceSource
-.. |image0| image:: media/mandatory.jpg
+.. |image0| image:: media/mandatory.JPG
:width: 7.88889in
:height: 4.43750in
-.. |image1| image:: media/optional.jpg
+.. |image1| image:: media/optional.JPG
:width: 7.88889in
:height: 4.43750in \ No newline at end of file
diff --git a/docs/datadictionary/resourceDefinitionCode.rst b/docs/datadictionary/resourcedefinitioncodesnip.rst
index a91767678..a91767678 100644
--- a/docs/datadictionary/resourceDefinitionCode.rst
+++ b/docs/datadictionary/resourcedefinitioncodesnip.rst
diff --git a/docs/datadictionary/resourcesource.rst b/docs/datadictionary/resourcesource.rst
index 1a69fd63f..852a34f07 100644
--- a/docs/datadictionary/resourcesource.rst
+++ b/docs/datadictionary/resourcesource.rst
@@ -11,10 +11,13 @@ Expects the value to be provided as input to the request.
source-input:
+.. code: json
+print("
"description": "This is Input Resource Source Node Type",
"version": "1.0.0",
"properties": {},
"derived_from": "tosca.nodes.ResourceSource"
+")
Default:
@@ -39,21 +42,21 @@ CDS is currently deployed along the side of SDNC, hence the primary database con
|image0|
-.. |image0| image:: media/sqltable.jpg
+.. |image0| image:: media/sqltable.JPG
:width: 7.88889in
:height: 4.43750in
.. toctree::
:maxdepth: 1
-sourceprimarydbcode
+ sourceprimarydbcode
Connection to a specific database can be expressed through the endpoint-selector property, which refers to a macro defining the information about the database the connect to. Understand TOSCA Macro in the context of CDS.
.. toctree::
:maxdepth: 1
-dbsystemcode
+ dbsystemcode
REST:
@@ -65,7 +68,7 @@ CDS is currently deployed along the side of SDNC, hence the default rest connect
|image1|
-.. |image1| image:: media/resttable.jpg
+.. |image1| image:: media/resttable.JPG
:width: 7.88889in
:height: 4.43750in
@@ -96,7 +99,7 @@ Expects a script to be provided.
|image2|
-.. |image2| image:: media/capabilitytable.jpg
+.. |image2| image:: media/capabilitytable.JPG
:width: 7.88889in
:height: 4.43750in
@@ -104,7 +107,7 @@ Expects a script to be provided.
.. toctree::
:maxdepth: 1
- sourcecapabilitycode
+ sourcecapabilitycode
Complex Type:
=============
@@ -122,14 +125,14 @@ As part of this request, the expected response will be as below.
.. toctree::
:maxdepth: 1
- complexResponse
+ complexResponse
What is of interest is the address and id fields. For the process to return these two values, we need to create a custom data-type, as bellow
.. toctree::
:maxdepth: 1
- dt-netbox-ip
+ dt-netbox-ip
The type of the data dictionary will be dt-netbox-ip.
@@ -138,4 +141,4 @@ To tell the resolution framework what is of interest in the response, the output
.. toctree::
:maxdepth: 1
-create_netbox_ip_address \ No newline at end of file
+ create_netbox_ip_address \ No newline at end of file
diff --git a/docs/index.rst b/docs/index.rst
index 794d87fb5..45b124f29 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -23,8 +23,32 @@ its parameters and create a new service without writing a single line of code.
This makes SERVICE PROVIDER(S) more responsive to its customers and able to
deliver products that more closely match the needs of its customers.
+Architecture
+------------
+The Controller Design Studio is composed of two major components:
+ * The GUI (or frontend)
+ * The Run Time (or backend)
+
+The GUI handles direct user input and allows for displaying both design time
+and run time activities. For design time, it allows for the creation of
+controller blueprint, from selecting the DGs to be included, to incorporating
+the artifact templates, to adding necessary components. For run time, it
+allows the user to direct the system to resolve the unresolved elements of the
+controller blueprint and download the resulting configuration into a VNF.
+At a more basic level, it allows for creation of data dictionaries,
+capabilities catalogs, and controller blueprint, the basic elements that are
+used to generate a configuration. The essential function of the Controller
+Design Studio is to create and populate a controller blueprint, create a
+configuration file from this Controller blueprint, and download this
+configuration file (configlet) to a VNF/PNF.
+
+|image1|
+
+
+
Modeling Concept
-----------------
+================
+
In Dublin release, the CDS community has contributed a framework to automate
the resolution of resources for instantiation and any config provisioning
operation, such as day0, day1 or day2 configuration.
@@ -44,68 +68,45 @@ Tosca Model Reference:
|image0|
-Design tools
-------------
-.. toctree::
- :maxdepth: 1
- :glob:
-
- CBA/index
- datadictionary/index
+Modeling Concept Links:
+-----------------------
-MicroServices
--------------
.. toctree::
:maxdepth: 1
microservices/controllerBlueprintStudioProcessorMS
microservices/bluePrintsProcessorMS
+ microservices/expression
+ microservices/dynamicapi
+ microservices/flexibleplugin
-Architecture
-------------
-The Controller Design Studio is composed of two major components:
- * The GUI (or frontend)
- * The Run Time (or backend)
-
-The GUI handles direct user input and allows for displaying both design time
-and run time activities. For design time, it allows for the creation of
-controller blueprint, from selecting the DGs to be included, to incorporating
-the artifact templates, to adding necessary components. For run time, it
-allows the user to direct the system to resolve the unresolved elements of the
-controller blueprint and download the resulting configuration into a VNF.
-At a more basic level, it allows for creation of data dictionaries,
-capabilities catalogs, and controller blueprint, the basic elements that are
-used to generate a configuration. The essential function of the Controller
-Design Studio is to create and populate a controller blueprint, create a
-configuration file from this Controller blueprint, and download this
-configuration file (configlet) to a VNF/PNF.
-
-|image1|
-
-User Guide
-----------
+Design tools
+============
.. toctree::
:maxdepth: 1
+ :glob:
- userguide
+ CBA/index
+ datadictionary/index
-Dynamic API
------------
-.. toctree::
- :maxdepth: 1
- microservices/dynamicapi
-Controller Design Studio Presentation
--------------------------------------
+Scripts
+=======
-Details about CDS Architecture and Design detail, Please click the link.
-:download:`CDS_Architecture_Design.pptx`
+Library
+-------
+
+*NetconfClient
+--------------
+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
-ResolutionHelper
-----------------
+*ResolutionHelper
+-----------------
When executing a component executor script, designer might want to perform
resource resolution along with template meshing directly from the script
itself.
@@ -120,4 +121,17 @@ The helper can be find here: https://github.com/onap/ccsdk-apps/blob/master/comp
:height: 4.43750in
:width: 7.88889in
+User Guide
+----------
+
+.. toctree::
+ :maxdepth: 1
+
+ userguide
+
+
+Controller Design Studio Presentation
+-------------------------------------
+Details about CDS Architecture and Design detail, Please click the link.
+:download:`CDS_Architecture_Design.pptx`
diff --git a/docs/microservices/bluePrintsProcessorMS.rst b/docs/microservices/bluePrintsProcessorMS.rst
index 911f99945..3f308138f 100644
--- a/docs/microservices/bluePrintsProcessorMS.rst
+++ b/docs/microservices/bluePrintsProcessorMS.rst
@@ -14,7 +14,7 @@ Micro service to Manage Controller Blueprint Models, such as Resource Dictionary
This microservice is used to deploy Controller Blueprint Archive file in Run time database. This also helps to test the Valid Blueprint.
Architecture:
-==============
+-------------
|image0|
@@ -23,7 +23,7 @@ Architecture:
:width: 800px
Running Blueprints Processor Microservice Locally:
-==================================================
+--------------------------------------------------
The purpose of this page is to show how to run the Blueprints Processor microservice locally, using the docker-compose.yaml file provided in the project.
@@ -48,7 +48,7 @@ Build it using the Maven profile called Docker:
mvn clean install -Pdocker
Start Docker containers using docker-composer:
-==============================================
+----------------------------------------------
Navigate to the docker-compose file in the distribution module:
@@ -66,7 +66,7 @@ To verify the logs generated by docker-composer, type:
Testing the environment:
-========================
+------------------------
Point your browser to http://localhost:8000/api/v1/execution-service/ping (please note that the port is 8000, not 8080)
diff --git a/docs/microservices/controllerBlueprintStudioProcessorMS.rst b/docs/microservices/controllerBlueprintStudioProcessorMS.rst
index 5c67d6c1d..683b6943d 100644
--- a/docs/microservices/controllerBlueprintStudioProcessorMS.rst
+++ b/docs/microservices/controllerBlueprintStudioProcessorMS.rst
@@ -10,7 +10,7 @@ The Controller Blueprint Archive is the overall service design, fully model-driv
The CBA is .zip file which is saved in Controller Blueprint Database.
Dynamic API:
-===========
+------------
The nature of the API request and response is meant to be model driven and dynamic. They both share the same definition.
@@ -22,11 +22,18 @@ The first top level element will always be either $actionName-request for a requ
Then the content within this element is fully based on the workflow input and output.
+.. toctree::
+ :maxdepth: 1
+
+ dynamicapi
Enrichment:
-===========
+-----------
Helps to generate complete valid CBA file.
-
+.. toctree::
+ :maxdepth: 1
+
+ enrichment
\ No newline at end of file
diff --git a/docs/microservices/expression.rst b/docs/microservices/expression.rst
new file mode 100644
index 000000000..38a7d624c
--- /dev/null
+++ b/docs/microservices/expression.rst
@@ -0,0 +1,45 @@
+.. This work is licensed under a Creative Commons Attribution 4.0
+.. International License. http://creativecommons.org/licenses/by/4.0
+.. Copyright (C) 2019 IBM.
+
+Expression
+==========
+
+TOSCA provides for a set of functions to reference elements within the template or to retrieve runtime values.
+
+Below is a list of supported expressions
+
+get_input
+---------
+
+The get_input function is used to retrieve the values of properties declared within the inputs section of a TOSCA Service Template.
+
+http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454178
+
+get_property
+------------
+
+The get_property function is used to retrieve property values between modelable entities defined in the same service template.
+
+http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454178
+
+get_attribute
+-------------
+
+The get_attribute function is used to retrieve the values of named attributes declared by the referenced node or relationship template name.
+
+http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454179
+
+get_operation_output
+--------------------
+
+The get_operation_output function is used to retrieve the values of variables exposed / exported from an interface operation.
+
+http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454180
+
+get_artifact
+------------
+
+The get_artifact function is used to retrieve artifact location between modelable entities defined in the same service template.
+
+http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454182
diff --git a/docs/media/blueprintprocessor.jpg b/docs/microservices/images/blueprintprocessor.jpg
index c618e0e32..c618e0e32 100644
--- a/docs/media/blueprintprocessor.jpg
+++ b/docs/microservices/images/blueprintprocessor.jpg
Binary files differ
diff --git a/docs/microservices/workflow.rst b/docs/microservices/workflow.rst
new file mode 100644
index 000000000..b74a49d2b
--- /dev/null
+++ b/docs/microservices/workflow.rst
@@ -0,0 +1,73 @@
+.. This work is licensed under a Creative Commons Attribution 4.0
+.. International License. http://creativecommons.org/licenses/by/4.0
+.. Copyright (C) 2019 IBM.
+
+Workflow
+========
+
+A workflow defines an overall action to be taken on the service, hence is an entry-point for the run-time execution of the CBA package.
+
+A workflow also defines inputs and outputs that will defined the payload contract of the request and response (see Dynamic API)
+
+A workflow can be composed of one or multiple sub-actions to execute.
+
+A CBA package can have as many workflows as needed.
+
+Single action
+-------------
+
+The workflow is directly backed by a node_template of type tosca.nodes.Component
+
+Multiple sub-actions
+--------------------
+The workflow is backed by Directed Graph engine, node_template of type dg-generic, and are imperative workflows.
+
+A DG used as workflow for CDS is composed of multiple execute nodes; each individual execute node refers to a plugin, that is a node_template of type tosca.nodes.Component.
+
+Below the properties of a workflow:
+
+
+
+Workflow Example
+----------------
+
+.. code:: json
+
+print("
+{
+ "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"
+ }
+ },
+ "steps": {
+ "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": {
+ "get_attribute": [ <- uses expression to retrieve attribute from context
+ "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 \ No newline at end of file