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/expression.rst45
-rw-r--r--docs/microservices/flexibleplugin.rst (renamed from docs/flexibleplugin.rst)0
-rw-r--r--docs/microservices/workflow.rst73
7 files changed, 193 insertions, 58 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/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/flexibleplugin.rst b/docs/microservices/flexibleplugin.rst
index 5c83ac9b7..5c83ac9b7 100644
--- a/docs/flexibleplugin.rst
+++ b/docs/microservices/flexibleplugin.rst
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