diff options
Diffstat (limited to 'docs')
-rw-r--r-- | docs/datadictionary/index.rst | 6 | ||||
-rw-r--r-- | docs/datadictionary/resourcedefinitioncodesnip.rst (renamed from docs/datadictionary/resourceDefinitionCode.rst) | 0 | ||||
-rw-r--r-- | docs/datadictionary/resourcesource.rst | 21 | ||||
-rw-r--r-- | docs/index.rst | 106 | ||||
-rw-r--r-- | docs/microservices/expression.rst | 45 | ||||
-rw-r--r-- | docs/microservices/flexibleplugin.rst (renamed from docs/flexibleplugin.rst) | 0 | ||||
-rw-r--r-- | docs/microservices/workflow.rst | 73 |
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 |