.. _cds_cba-doc:
-Controller Blueprint Archived Designer Tool(CBA)
-================================================
+Controller Blueprint Archived Designer Tool (CBA)
+=================================================
.. toctree::
:maxdepth: 1
Introduction
------------
-The Controller Blueprint Archived is the overall service design, fully
-model-driven, package needed to automate the resolution of resources for
-instantiation and any config provisioning operation, such as day0,
-day1 or day2 configuration.
-
-The CBA is .zip file, comprised of the following folder structure, the
-files may vary:
-
-|image0|
+The **C**\ ontroller **B**\ lueprint **A**\ rchive is the overall service design, fully model-driven, intent based
+**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:
+
+.. code-block language is required for ReadTheDocs to render code-blocks. Python set as default.
+
+.. code-block:: python
+
+ ├── 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.
Architecture
------------
+|image1|
-|image3|
+Data Flow
+---------
+|image2|
Installation
Functional Decomposition
------------------------
-|image2|
+|image3|
+
+.. |image1| image:: media/CDS_Architecture.jpg
+ :width: 500pt
-.. |image0| image:: media/image0.jpg
- :width: 7.88889in
- :height: 4.43750in
+.. |image2| image:: media/CDS_Data_Flow.jpg
+ :width: 500pt
-.. |image2| image:: media/image2.jpg
- :width: 7.88889in
- :height: 4.43750in
+.. |image3| image:: media/Functional_Decomposition.jpg
+ :width: 500pt
-.. |image3| image:: media/CDS_architecture.jpg
- :height: 4.43750in
- :width: 7.88889in
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-.. Copyright (C) 2019 IBM.
-
-complex Response code
-=====================
-
-.. code-block:: json
- :linenos:
-
- {
- "id": 4,
- "address": "192.168.10.2/32",
- "vrf": null,
- "tenant": null,
- "status": 1,
- "role": null,
- "interface": null,
- "description": "",
- "nat_inside": null,
- "created": "2018-08-30",
- "last_updated": "2018-08-30T14:59:05.277820Z"
- }
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-.. Copyright (C) 2019 IBM.
-
-create_netbox_ip_address code
-=============================
-
-.. code-block:: json
-
- {
- "tags" : "oam-local-ipv4-address",
- "name" : "create_netbox_ip",
- "property" : {
- "description" : "netbox ip",
- "type" : "dt-netbox-ip"
- },
- "updated-by" : "adetalhouet",
- "sources" : {
- "config-data" : {
- "type" : "source-rest",
- "properties" : {
- "type" : "JSON",
- "verb" : "POST",
- "endpoint-selector" : "ipam-1",
- "url-path" : "/api/ipam/prefixes/$prefixId/available-ips/",
- "path" : "",
- "input-key-mapping" : {
- "prefixId" : "prefix-id"
- },
- "output-key-mapping" : {
- "address" : "address",
- "id" : "id"
- },
- "key-dependencies" : [ "prefix-id" ]
- }
- }
- }
- }
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-.. Copyright (C) 2019 IBM.
-
-Dbsystemcode
-============
-.. code-block:: json
- :linenos:
-
- {
- "dsl_definitions": {
- "dynamic-db-source": {
- "type": "maria-db",
- "url": "jdbc:mysql://localhost:3306/sdnctl",
- "username": "<username>",
- "password": "<password>"
- }
- }
- }
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-.. Copyright (C) 2019 IBM.
-
-dt-netbox-ip code
-=================
-
-.. code-block:: none
- :linenos:
-
- {
- "version": "1.0.0",
- "description": "This is Netbox IP Data Type",
- "properties": {
- "address": {
- "required": true,
- "type": "string"
- },
- "id": {
- "required": true,
- "type": "integer"
- }
- },
- "derived_from": "tosca.datatypes.Root"
- }
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-.. Copyright (C) 2019 IBM.
-
-Source Capability Code
-======================
-
-.. code-block:: json
- :linenos:
-
- {
- "description": "This is Component Resource Source Node Type",
- "version": "1.0.0",
- "properties": {
- "script-type": {
- "required": true,
- "type": "string",
- "default": "kotlin",
- "constraints": [
- {
- "valid_values": [
- "kotlin",
- "jython"
- ]
- }
- ]
- },
- "script-class-reference": {
- "description": "Capability reference name for internal and kotlin, for jython script file path",
- "required": true,
- "type": "string"
- },
- "instance-dependencies": {
- "required": false,
- "description": "Instance dependency Names to Inject to Kotlin / Jython Script.",
- "type": "list",
- "entry_schema": {
- "type": "string"
- }
- },
- "key-dependencies": {
- "description": "Resource Resolution dependency dictionary names.",
- "required": true,
- "type": "list",
- "entry_schema": {
- "type": "string"
- }
- }
- },
- "derived_from": "tosca.nodes.ResourceSource"
- }
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-.. Copyright (C) 2019 IBM.
-
-Resource Source
----------------
-
-Input:
-======
-Expects the value to be provided as input to the request.
-
-
-.. code-block:: json
- :linenos:
-
- {
- "source-input" :
- {
- "description": "This is Input Resource Source Node Type",
- "version": "1.0.0",
- "properties": {},
- "derived_from": "tosca.nodes.ResourceSource"
- }
- }
-
-
-
-Default:
-========
-Expects the value to be defaulted in the model itself.
-
-
-.. code-block:: json
- :linenos:
-
- {
- "source-default" :
- {
- "description": "This is Default Resource Source Node Type",
- "version": "1.0.0",
- "properties": {},
- "derived_from": "tosca.nodes.ResourceSource"
- }
- }
-
-
-sql:
-====
-
-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 connection provided by the framework is to SDNC database.
-
-|image0|
-
-.. |image0| image:: media/sqltable.JPG
- :width: 7.88889in
- :height: 4.43750in
-
-.. toctree::
- :maxdepth: 1
-
- 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
-
-
-REST:
-=====
-
-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 connection provided by the framework is to SDNC MDSAL.
-
-|image1|
-
-.. |image1| image:: media/resttable.JPG
- :width: 7.88889in
- :height: 4.43750in
-
-.. toctree::
- :maxdepth: 1
-
- restsourcecode
-
-Connection to a specific REST system can be expressed through the endpoint-selector property, which refers to a macro defining the information about the REST system the connect to. Understand TOSCA Macro in the context of CDS.
-
-Few ways are available to authenticate to the REST system:
-
- * token-auth
- * basic-auth
- * ssl-basic-auth
-
-For source code of Authentication click below link:
-
-.. toctree::
- :maxdepth: 1
-
- restauth
-
-Capability:
-===========
-
-Expects a script to be provided.
-
-|image2|
-
-.. |image2| image:: media/capabilitytable.JPG
- :width: 7.88889in
- :height: 4.43750in
-
-
-.. toctree::
- :maxdepth: 1
-
- sourcecapabilitycode
-
-Complex Type:
-=============
-
-Value will be resolved through REST., and output will be a complex type.
-
-Modeling reference: Modeling Concepts#rest
-
-In this example, we're making a POST request to an IPAM system with no payload.
-
-Some ingredients are required to perform the query, in this case, $prefixId. Hence It is provided as an input-key-mapping and defined as a key-dependencies. Please refer to the modeling guideline for more in depth understanding.
-
-As part of this request, the expected response will be as below.
-
-.. toctree::
- :maxdepth: 1
-
- 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
-
-The type of the data dictionary will be dt-netbox-ip.
-
-To tell the resolution framework what is of interest in the response, the output-key-mapping section is used. The process will map the output-key-mapping to the defined data-type.
-
-.. toctree::
- :maxdepth: 1
-
- create_netbox_ip_address
\ No newline at end of file
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-.. Copyright (C) 2019 IBM.
-
-
-Resource Rest Authentication
-----------------------------
-
-token-auth:
-~~~~~~~~~~~
-
-.. code-block:: json
- :linenos:
-
- {
- "dsl_definitions": {
- "dynamic-rest-source": {
- "type" : "token-auth",
- "url" : "http://localhost:32778",
- "token" : "<token>"
- }
- }
- }
-
-basic-auth:
-~~~~~~~~~~~
-
-.. code-block:: json
- :linenos:
-
- {
- "dsl_definitions": {
- "dynamic-rest-source": {
- "type" : "basic-auth",
- "url" : "http://localhost:32778",
- "username" : "<username>",
- "password": "<password>"
- }
- }
- }
-
-ssl-basic-auth:
-~~~~~~~~~~~~~~~
-
-.. code-block:: json
- :linenos:
-
- {
- "dsl_definitions": {
- "dynamic-rest-source": {
- "type" : "ssl-basic-auth",
- "url" : "http://localhost:32778",
- "keyStoreInstance": "JKS or PKCS12",
- "sslTrust": "trusture",
- "sslTrustPassword": "<password>",
- "sslKey": "keystore",
- "sslKeyPassword": "<password>"
- }
- }
- }
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-.. Copyright (C) 2019 IBM.
-
-Rest Source Code:
-=================
-
-.. code-block:: json
- :linenos:
-
- {
- "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"
- }
- }
- },
- "derived_from": "tosca.nodes.ResourceSource"
- }
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-.. Copyright (C) 2019 IBM.
-
-Source Capability Code
-======================
-
-.. code-block:: json
- :linenos:
-
- {
- "description": "This is Component Resource Source Node Type",
- "version": "1.0.0",
- "properties": {
- "script-type": {
- "required": true,
- "type": "string",
- "default": "kotlin",
- "constraints": [
- {
- "valid_values": [
- "kotlin",
- "jython"
- ]
- }
- ]
- },
- "script-class-reference": {
- "description": "Capability reference name for internal and kotlin, for jython script file path",
- "required": true,
- "type": "string"
- },
- "key-dependencies": {
- "description": "Resource Resolution dependency dictionary names.",
- "required": true,
- "type": "list",
- "entry_schema": {
- "type": "string"
- }
- }
- },
- "derived_from": "tosca.nodes.ResourceSource"
- }
-
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-.. Copyright (C) 2019 IBM.
-
-Source Default code
-===================
-
-.. code-block:: json
- :linenos:
-
- {
- "description": "This is Default Resource Source Node Type",
- "version": "1.0.0",
- "properties": {},
- "derived_from": "tosca.nodes.ResourceSource"
- }
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-.. Copyright (C) 2019 IBM.
-
-Source Input code
-=================
-
-.. code-block:: json
- :linenos:
-
- {
- "description": "This is Input Resource Source Node Type",
- "version": "1.0.0",
- "properties": {},
- "derived_from": "tosca.nodes.ResourceSource"
- }
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-.. Copyright (C) 2019 IBM.
-
-Source Primary DB Code:
-=======================
-
-.. code-block:: json
- :linenos:
-
- {
- "description": "This is Database Resource Source Node Type",
- "version": "1.0.0",
- "properties": {
- "type": {
- "required": true,
- "type": "string",
- "constraints": [
- {
- "valid_values": [
- "SQL"
- ]
- }
- ]
- },
- "endpoint-selector": {
- "required": false,
- "type": "string"
- },
- "query": {
- "required": true,
- "type": "string"
- },
- "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"
- }
- }
- },
- "derived_from": "tosca.nodes.ResourceSource"
- }
Introduction
------------
-The system is designed to be self service, which means that users, not just
+ The system is designed to be self service, which means that users, not just
programmers, can reconfigure the software system as needed to meet customer
requirements. To accomplish this goal, the system is built around models that
provide for real-time changes in how the system operates. Users merely need
to change a model to change how a service operates.
-Self service is a completely new way of delivering services. It removes the
+
+ Self service is a completely new way of delivering services. It removes the
dependence on code releases and the delays they cause and puts the control of
services into the hands of the service providers. They can change a model and
its parameters and create a new service without writing a single line of code.
* The GUI (or frontend)
* The Run Time (or backend)
-The GUI handles direct user input and allows for displaying both design time
+ 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,
+
+ 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
Modeling Concept
----------------
-In Dublin release, the CDS community has contributed a framework to automate
+ 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.
-The content of the CBA Package is driven from a catalog of reusable data
+ The content of the CBA Package is driven from a catalog of reusable data
dictionary, component and workflow, delivering a reusable and simplified
self service experience.
Tosca Model Reference:
-|image0|
+|toscaModel|
Modeling Concept Links:
~~~~~~~~~~~~~~~~~~~~~~~
.. toctree::
:maxdepth: 1
- modelingconcepts/overview
- microservices/controllerBlueprintStudioProcessorMS
- microservices/bluePrintsProcessorMS
- microservices/expression
- microservices/dynamicapi
- microservices/flexibleplugin
-
-
-Design tools
-------------
-.. toctree::
- :maxdepth: 1
- :glob:
-
- CBA/index
- datadictionary/index
+ modelingconcepts/index
+ microservices/controllerBlueprintMS
+ microservices/blueprintsProcessorMS
Scripts
-------
* 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.
+ 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
+ The client can be find here: https://github.com/onap/ccsdk-cds/blob/master/components/scripts/python/ccsdk_netconf/netconfclient.py
* ResolutionHelper
-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 found in below link:
-https://github.com/onap/ccsdk-apps/blob/master/components/scripts/python/ccsdk_netconf/common.py
+ When executing a component executor script, designer might want to perform
+ resource resolution along with template meshing directly from the script
+ itself.
-.. |image0| image:: media/tosca_model.jpg
- :width: 7.88889in
- :height: 4.43750in
+ The helper can be found in below link:
+ https://github.com/onap/ccsdk-apps/blob/master/components/scripts/python/ccsdk_netconf/common.py
-.. |cdsArchitectureImage| image:: media/CDS_architecture_latest.png
- :scale: 30 %
+.. |toscaModel| image:: media/tosca_model.jpg
+ :width: 500pt
-Developer Guide
-----------
-
-.. toctree::
- :maxdepth: 2
-
- developerguide/developer-guide
+.. |cdsArchitectureImage| image:: media/CDS_architecture.jpg
+ :width: 500pt
User Guide
----------
.. toctree::
- :maxdepth: 1
+ :maxdepth: 3
- installation
- designtime
+ userguide/developer-guide
+ userguide/installation
+ userguide/designtime
Use Cases
-----------
+---------
.. toctree::
:maxdepth: 2
usecases/use-cases
-CDS Desginer UI
+CDS Designer UI
---------------
.. toctree::
- :maxdepth: 1
+ :maxdepth: 2
- CDS_Designer_Guide
+ ui/designer
Controller Design Studio Presentation
-------------------------------------
Details about CDS Architecture and Design detail, Please click the link.
-:download:`CDS_Architecture_Design.pptx`
+:download:`CDS_Architecture_Design <media/CDS_Architecture_Design.pptx>`
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-.. Copyright (C) 2019 IBM.
-
-Logging
--------
-.. toctree::
- :maxdepth: 1
-
-CCSDK uses slf4j to log messages to the standard OpenDaylight karaf.log
-log file.
-
-Where to Access Information
----------------------------
-Logs are found within the SDNC docker container, in the directory
-/opt/opendaylight/current/data/logs.
\ No newline at end of file
.. toctree::
:maxdepth: 1
:titlesonly:
-
+
Micro service to Manage Controller Blueprint Models, such as Resource Dictionary, Service Models, Velocity Templates etc, which will serve service for Controller Design Studio and Controller runtimes.
This microservice is used to deploy Controller Blueprint Archive file in Run time database. This also helps to test the Valid Blueprint.
|image0|
-.. |image0| image:: images/blueprintprocessor.jpg
- :height: 600px
- :width: 800px
-
+.. |image0| image:: media/blueprintprocessor.jpg
+ :width: 400pt
+
Running Blueprints Processor Microservice Locally:
--------------------------------------------------
In the checked out directory, type
.. code-block:: none
-
+
mvn clean install -DskipTests=true -Dmaven.test.skip=true -Dmaven.javadoc.skip=true -Dadditionalparam=-Xdoclint:none
-
+
Create the needed Docker images:
The Blueprints Processor microservice project has a module, called distribution, that provides a docker-compose.yaml file that can be used to spin up Docker containers to run this microservice.
.. code-block:: none
cd ms/blueprintsprocessor/distribution/
-
+
Build it using the Maven profile called Docker:
.. code-block:: none
mvn clean install -Pdocker
-
+
Start Docker containers using docker-composer:
----------------------------------------------
Navigate to the docker-compose file in the distribution module:
.. code-block:: none
-
+
cd src/main/dc/
-
+
From there, start the containers:
.. code-block:: none
docker-compose up -d
-
+
This will spin the Docker containers declared inside the docker-compose.yaml file in the background.
.. code-block:: none
docker-compose logs -f
-
-
+
+
Testing the environment:
------------------------
Controller Blueprints Studio Processor
======================================
-The Controller Blueprint Archive is the overall service design, fully model-driven, intent based package needed for SELF SERVICE provisioning and configuration management automation.
+The **C**\ ontroller **B**\ lueprint **A**\ rchive is the overall service design, fully model-driven, intent based
+**package** needed for SELF SERVICE provisioning and configuration management automation.
-The CBA is .zip file which is saved in Controller Blueprint Database.
+The CBA is .zip file, which is saved in Controller Blueprint Database.
Controller Blueprint Microservices:
-----------------------------------
.. toctree::
:maxdepth: 1
-
+
dynamicapi
enrichment
-
\ No newline at end of file
.. Copyright (C) 2019 IBM.
Dynamic API
------------
+===========
The nature of the API request and response is meant to be model driven and dynamic. They both share the same definition.
|image0|
.. |image0| image:: media/dyanmicapi.jpg
- :height: 4.43750in
- :width: 7.88889in
\ No newline at end of file
+ :width: 500pt
\ No newline at end of file
|image2|
.. |image0| image:: media/Enrichment-REST.png
- :width: 7.88889in
- :height: 4.43750in
-
+ :width: 500pt
+
.. |image1| image:: media/Enrichment-UI1.png
- :width: 7.88889in
- :height: 4.43750in
-
+ :width: 500pt
+
.. |image2| image:: media/Enrichment-UI2.png
- :width: 7.88889in
- :height: 4.43750in
\ No newline at end of file
+ :width: 500pt
\ No newline at end of file
+++ /dev/null
-.. 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
+++ /dev/null
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-.. Copyright (C) 2019 IBM.
-
-Flexible Plug-in
-----------------
-
-Interaction with external systems is made plug-able, removing development cycle to support new endpoint.
-
-Currently, REST or SQL external systems are supported.
-
-An external system might be used by multiple resources, or by multiple scripts.
-
-In order to share the external system information, TOSCA provides a way to create macros using dsl_definitions:
-
-http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454160
-http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454173
.. _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>`_
: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**
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
: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
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`.
: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
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
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>`_
: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.
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
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:
: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"
}
.. 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:
.. 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
.. _data_dictionary:
Data Dictionary
------------------
+---------------
A data dictionary **models the how** a specific **resource** can be **resolved**.
- The creator
- Mandatory
* - tags
- - Information related
+ - Information related
- Mandatory
* - sources
- List of resource source instance (see :ref:`resource source`)
- 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::
- 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:
* - vf-module-label data dictionary
* - .. 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
.. _data_type:
Data type
--------------------------------------
+---------
Represents the **schema** of a specific type of **data**.
- * 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.
**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": {
-
"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>"
-
}
-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
.. 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
: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": false,
"type": "string"
}
- },
- "derived_from": "tosca.datatypes.Root"
+ },
+ "derived_from": "tosca.datatypes.Root"
}
\ No newline at end of file
.. 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.
- 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`)
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
.. _enrichment:
Enrichment
------------
+----------
The idea is that the CBA is a self-sufficient package, hence requires
all the various types definition its using.
* 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:
.. _expression:
Expression
--------------------------------------
+----------
TOSCA provides for a set of functions to reference elements within the template or to retrieve runtime values.
**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"
**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
--- /dev/null
+.. 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"
+ }
+ }
+ . . .
+ }
+++ /dev/null
-.. 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
.. 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
: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
.. _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::
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.
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": {
}
},
"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
.. _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": {
"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,
}
},
"derived_from": "tosca.nodes.Component"
- }
+ }
.. tab:: remote-script-executor
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
}
]
- 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",
]
}
}
- }
- 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
.. 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
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
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
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::
* - 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::
- 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
* - 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
* - 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.
"version": "1.0.0",
"derived_from": "tosca.nodes.Root"
}
-
+
**vnf-netconf-device**
Represents the VNF information to **establish** a **NETCONF communication**.
},
"derived_from": "tosca.nodes.Vnf"
}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
.. Copyright (C) 2020 Deutsche Telekom AG.
Scripts
--------------
+-------
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
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
.. 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:
* 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
.. _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:
.. 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:
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
.. 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.
- 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
**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
.. _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.
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>`_
: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
**************************
- 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.
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`)
- 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`)
.. 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>`_
.. http://creativecommons.org/licenses/by/4.0
.. Copyright (C) 2019 IBM.
-Resource Definition
+Resource Definition
-------------------
.. toctree::
- :maxdepth: 1
+ :maxdepth: 2
Introduction:
=============
|image0|
-
Below are properties that all the resource source have will have
The modeling does allow for data translation between external capability and CDS for both input and output key mapping.
Here is how input-key-mapping, output-key-mapping and key-dependencies can be used:
-.. toctree::
- :maxdepth: 1
-
- resourcedefinitioncodesnip
+.. code-block:: json
+ :linenos:
+
+ {
+ "description": "This is Component Resource Source Node Type",
+ "version": "1.0.0",
+ "properties": {
+ "script-type": {
+ "required": true,
+ "type": "string",
+ "default": "kotlin",
+ "constraints": [
+ {
+ "valid_values": [
+ "kotlin",
+ "jython"
+ ]
+ }
+ ]
+ },
+ "script-class-reference": {
+ "description": "Capability reference name for internal and kotlin, for jython script file path",
+ "required": true,
+ "type": "string"
+ },
+ "instance-dependencies": {
+ "required": false,
+ "description": "Instance dependency Names to Inject to Kotlin / Jython Script.",
+ "type": "list",
+ "entry_schema": {
+ "type": "string"
+ }
+ },
+ "key-dependencies": {
+ "description": "Resource Resolution dependency dictionary names.",
+ "required": true,
+ "type": "list",
+ "entry_schema": {
+ "type": "string"
+ }
+ }
+ },
+ "derived_from": "tosca.nodes.ResourceSource"
+ }
Resource source:
Also please click below for resource source available details
.. toctree::
- :maxdepth: 1
-
+ :maxdepth: 4
+
resourcesource
.. _TOSCA: http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/csprd01/TOSCA-Simple-Profile-YAML-v1.0-csprd01.html#DEFN_ENTITY_NODE_TYPE
.. |image0| image:: media/mandatory.JPG
- :width: 7.88889in
- :height: 4.43750in
-
+ :width: 400pt
+
.. |image1| image:: media/optional.JPG
- :width: 7.88889in
- :height: 4.43750in
\ No newline at end of file
+ :width: 400pt
\ No newline at end of file
--- /dev/null
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. Copyright (C) 2019 IBM.
+
+Resource Source
+---------------
+.. toctree::
+ :maxdepth: 4
+
+Input:
+======
+Expects the value to be provided as input to the request.
+
+.. code-block:: json
+ :linenos:
+
+ {
+ "source-input" :
+ {
+ "description": "This is Input Resource Source Node Type",
+ "version": "1.0.0",
+ "properties": {},
+ "derived_from": "tosca.nodes.ResourceSource"
+ }
+ }
+
+Default:
+========
+Expects the value to be defaulted in the model itself.
+
+.. code-block:: json
+ :linenos:
+
+ {
+ "source-default" :
+ {
+ "description": "This is Default Resource Source Node Type",
+ "version": "1.0.0",
+ "properties": {},
+ "derived_from": "tosca.nodes.ResourceSource"
+ }
+ }
+
+Sql:
+====
+
+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 connection provided by the framework is to SDNC database.
+
+|image0|
+
+.. |image0| image:: media/sqltable.JPG
+ :width: 400pt
+
+.. code-block:: json
+ :linenos:
+
+ {
+ "description": "This is Database Resource Source Node Type",
+ "version": "1.0.0",
+ "properties": {
+ "type": {
+ "required": true,
+ "type": "string",
+ "constraints": [
+ {
+ "valid_values": [
+ "SQL"
+ ]
+ }
+ ]
+ },
+ "endpoint-selector": {
+ "required": false,
+ "type": "string"
+ },
+ "query": {
+ "required": true,
+ "type": "string"
+ },
+ "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"
+ }
+ }
+ },
+ "derived_from": "tosca.nodes.ResourceSource"
+ }
+
+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.
+
+.. code-block:: json
+ :linenos:
+
+ {
+ "dsl_definitions": {
+ "dynamic-db-source": {
+ "type": "maria-db",
+ "url": "jdbc:mysql://localhost:3306/sdnctl",
+ "username": "<username>",
+ "password": "<password>"
+ }
+ }
+ }
+
+Rest:
+=====
+
+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 connection provided by the framework is to SDNC MDSAL.
+
+|image1|
+
+.. |image1| image:: media/optional.JPG
+ :width: 400pt
+
+.. code-block:: json
+ :linenos:
+
+ {
+ "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"
+ }
+ }
+ },
+ "derived_from": "tosca.nodes.ResourceSource"
+ }
+
+Connection to a specific REST system can be expressed through the endpoint-selector property, which refers to a macro defining the information about the REST system the connect to. Understand TOSCA Macro in the context of CDS.
+
+Few ways are available to authenticate to the REST system:
+ * token-auth
+ * basic-auth
+ * ssl-basic-auth
+
+token-auth:
+~~~~~~~~~~~
+
+.. code-block:: json
+ :linenos:
+
+ {
+ "dsl_definitions": {
+ "dynamic-rest-source": {
+ "type" : "token-auth",
+ "url" : "http://localhost:32778",
+ "token" : "<token>"
+ }
+ }
+ }
+
+basic-auth:
+~~~~~~~~~~~
+
+.. code-block:: json
+ :linenos:
+
+ {
+ "dsl_definitions": {
+ "dynamic-rest-source": {
+ "type" : "basic-auth",
+ "url" : "http://localhost:32778",
+ "username" : "<username>",
+ "password": "<password>"
+ }
+ }
+ }
+
+ssl-basic-auth:
+~~~~~~~~~~~~~~~
+
+.. code-block:: json
+ :linenos:
+
+ {
+ "dsl_definitions": {
+ "dynamic-rest-source": {
+ "type" : "ssl-basic-auth",
+ "url" : "http://localhost:32778",
+ "keyStoreInstance": "JKS or PKCS12",
+ "sslTrust": "trusture",
+ "sslTrustPassword": "<password>",
+ "sslKey": "keystore",
+ "sslKeyPassword": "<password>"
+ }
+ }
+ }
+
+Capability:
+===========
+
+Expects a script to be provided.
+
+|image2|
+
+.. |image2| image:: media/capabilitytable.JPG
+ :width: 400pt
+
+.. code-block:: json
+ :linenos:
+
+ {
+ "description": "This is Component Resource Source Node Type",
+ "version": "1.0.0",
+ "properties": {
+ "script-type": {
+ "required": true,
+ "type": "string",
+ "default": "kotlin",
+ "constraints": [
+ {
+ "valid_values": [
+ "kotlin",
+ "jython"
+ ]
+ }
+ ]
+ },
+ "script-class-reference": {
+ "description": "Capability reference name for internal and kotlin, for jython script file path",
+ "required": true,
+ "type": "string"
+ },
+ "instance-dependencies": {
+ "required": false,
+ "description": "Instance dependency Names to Inject to Kotlin / Jython Script.",
+ "type": "list",
+ "entry_schema": {
+ "type": "string"
+ }
+ },
+ "key-dependencies": {
+ "description": "Resource Resolution dependency dictionary names.",
+ "required": true,
+ "type": "list",
+ "entry_schema": {
+ "type": "string"
+ }
+ }
+ },
+ "derived_from": "tosca.nodes.ResourceSource"
+ }
+
+Complex Type:
+=============
+
+Value will be resolved through REST., and output will be a complex type.
+
+Modeling reference: Modeling Concepts#rest
+
+In this example, we're making a POST request to an IPAM system with no payload.
+
+Some ingredients are required to perform the query, in this case, $prefixId. Hence It is provided as an input-key-mapping and defined as a key-dependencies. Please refer to the modeling guideline for more in depth understanding.
+
+As part of this request, the expected response will be as below.
+
+.. code-block:: json
+ :linenos:
+
+ {
+ "id": 4,
+ "address": "192.168.10.2/32",
+ "vrf": null,
+ "tenant": null,
+ "status": 1,
+ "role": null,
+ "interface": null,
+ "description": "",
+ "nat_inside": null,
+ "created": "2018-08-30",
+ "last_updated": "2018-08-30T14:59:05.277820Z"
+ }
+
+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
+
+.. code-block:: json
+ :linenos:
+
+ {
+ "version": "1.0.0",
+ "description": "This is Netbox IP Data Type",
+ "properties": {
+ "address": {
+ "required": true,
+ "type": "string"
+ },
+ "id": {
+ "required": true,
+ "type": "integer"
+ }
+ },
+ "derived_from": "tosca.datatypes.Root"
+ }
+
+The type of the data dictionary will be dt-netbox-ip.
+
+To tell the resolution framework what is of interest in the response, the output-key-mapping section is used. The process will map the output-key-mapping to the defined data-type.
+
+.. code-block:: json
+
+ {
+ "tags" : "oam-local-ipv4-address",
+ "name" : "create_netbox_ip",
+ "property" : {
+ "description" : "netbox ip",
+ "type" : "dt-netbox-ip"
+ },
+ "updated-by" : "adetalhouet",
+ "sources" : {
+ "config-data" : {
+ "type" : "source-rest",
+ "properties" : {
+ "type" : "JSON",
+ "verb" : "POST",
+ "endpoint-selector" : "ipam-1",
+ "url-path" : "/api/ipam/prefixes/$prefixId/available-ips/",
+ "path" : "",
+ "input-key-mapping" : {
+ "prefixId" : "prefix-id"
+ },
+ "output-key-mapping" : {
+ "address" : "address",
+ "id" : "id"
+ },
+ "key-dependencies" : [ "prefix-id" ]
+ }
+ }
+ }
+ }
\ No newline at end of file
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. Copyright (C) 2019 IBM.
-
-CDS Designer Guide
-==================
+CDS Designer UI
+===============
**Table of Contents**
- `What is CDS Designer
UI? <file:////pages/viewpage.action%3fpageId=84650427#CDSDesignerGuide-WhatIsCDS>`__
-- `What’s
+- `What's
new? <file:////pages/viewpage.action%3fpageId=84650427#CDSDesignerGuide-WhatIsNew>`__
- `Overview of CDS
- `External System Authentication
Properties <#CDSDesignerGuide-ExternalSystem>`__
+
Getting Started
-===============
+---------------
This is your CDS Designer UI guide. No matter how experienced you are or
what you want to achieve, it should cover everything you need to know —
from navigating the interface to making the most of different features.
What is CDS Designer UI?
-========================
+------------------------
+----------------------------------------------+--------------+
| CDS Designer UI is a framework to automate | |
| CDS has both **design-time** and | |
| **run-time** activities; during design time, | |
| **Designer** can **define** what **actions** | |
-| are required for a given service, along with | |
-| anything comprising the action. The design | |
-| produces a `CBA | |
-| Package <https://wik | |
-| i.onap.org/display/DW/Modeling+Concepts#Mode | |
-| lingConcepts-ControllerBlueprintArchive>`__. | |
-| Its **content** is driven from a **catalog** | |
-| of **reusable data dictionary** and | |
-| **component**, delivering a reusable and | |
-| simplified **self-service** experience. | |
-| | |
-| CDS modeling is mainly based on **the TOSCA | |
-| standard**, using JSON as a representation. | |
+| are required for a given service, along with | |
+| anything comprising the action. The design | |
+| produces a `CBA | |
+| Package <https://wik | |
+| i.onap.org/display/DW/Modeling+Concepts#Mode | |
+| lingConcepts-ControllerBlueprintArchive>`__. | |
+| Its **content** is driven from a **catalog** | |
+| of **reusable data dictionary** and | |
+| **component**, delivering a reusable and | |
+| simplified **self-service** experience. | |
+| | |
+| CDS modeling is mainly based on **the TOSCA | |
+| standard**, using JSON as a representation. | |
+----------------------------------------------+--------------+
.. _section-3:
What's new?
-===========
+-----------
+----------------------+----------------------+----------------------+
| |image2| | |image3| | |image4| |
+----------------------+----------------------+----------------------+
Overview of CDS Interface
-=========================
+-------------------------
Full CDS UI screens are available in
`InVision <https://invis.io/PAUI9GLJH3Q>`__
and filtering
CBA Packages
-============
+------------
- .. rubric:: Package List
:name: package-list
screen
Create a New CBA Package
-========================
+------------------------
- .. rubric:: User Flow
:name: user-flow
|image29|
-.. |image1| image:: https://wiki.onap.org/download/attachments/84650426/CDS%20Logo.png?version=1&modificationDate=1591034588000&api=v2
+.. |image1| image:: https://wiki.onap.org/download/attachments/84650426/CDS%20Logo.png?version=1&modificationDate=1591034588000&api=v2
:width: 200pt
.. |image2| image:: https://wiki.onap.org/download/thumbnails/84650426/Feature%201.png?version=1&modificationDate=1591032224000&api=v2
:width: 50pt
:width: 500pt
.. |image28| image:: https://wiki.onap.org/download/attachments/84650426/Definitions%203.jpg?version=1&modificationDate=1591639556000&api=v2
:width: 500pt
-.. |image29| image:: https://wiki.onap.org/download/attachments/84650426/External%20system.jpg?version=1&modificationDate=1591639581000&api=v2
+.. |image29| image:: https://wiki.onap.org/download/attachments/84650426/External%20system.jpg?version=1&modificationDate=1591639581000&api=v2
:width: 500pt
\ No newline at end of file
.. Copyright (C) 2020 Deutsche Telekom AG.
Use Cases
-=================
+=========
.. toctree::
:caption: Table of Contents
.. Copyright (C) 2020 Deutsche Telekom AG.
Wordpress CNF in CDS (POC)
-=================
+==========================
This demo by CableLabs shows an easy to use POC how to use/deploy VNFs in CDS and do resource asignment.
.. http://creativecommons.org/licenses/by/4.0
.. Copyright (C) 2019 IBM.
-Design Time User Guide
-======================
+Design Time Tools Guide
+=======================
Below are the requirements to enable automation for a service within ONAP.
---------
.. toctree::
- :maxdepth: 1
-
- CBA/index
- datadictionary/index
+ :maxdepth: 2
+
+ ../CBA/index
+ ../resourcedefinition/index
resourceassignment
.. Copyright (C) 2019 IBM.
-User Guide
-==========
+Installation Guide
+==================
Installation
------------
.. code-block:: bash
:linenos:
-
+
$ kubectl get all --selector=release=cds
NAME READY STATUS RESTARTS AGE
pod/cds-blueprints-processor-54f758d69f-p98c2 0/1 Running 1 2m
pod/cds-cds-6bd674dc77-4gtdf 1/1 Running 0 2m
pod/cds-cds-db-0 1/1 Running 0 2m
pod/cds-controller-blueprints-545bbf98cf-zwjfc 1/1 Running 0 2m
+
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/blueprints-processor ClusterIP 10.43.139.9 <none> 8080/TCP,9111/TCP 2m
service/cds NodePort 10.43.254.69 <none> 3000:30397/TCP 2m
service/cds-db ClusterIP None <none> 3306/TCP 2m
service/controller-blueprints ClusterIP 10.43.207.152 <none> 8080/TCP 2m
+
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
deployment.apps/cds-blueprints-processor 1 1 1 0 2m
deployment.apps/cds-cds 1 1 1 1 2m
deployment.apps/cds-controller-blueprints 1 1 1 1 2m
+
NAME DESIRED CURRENT READY AGE
replicaset.apps/cds-blueprints-processor-54f758d69f 1 1 0 2m
replicaset.apps/cds-cds-6bd674dc77 1 1 1 2m
replicaset.apps/cds-controller-blueprints-545bbf98cf 1 1 1 2m
+
NAME DESIRED CURRENT AGE
statefulset.apps/cds-cds-db 1 1 2m
-
-
-
+
+
+
Running CDS UI:
---------------
~~~~~~~
Install Node.js and angularCLI. Refer https://angular.io/guide/quickstart
npm install in the directory cds/cds-ui/client
-npm run build - to build UI module
+npm run build - to build UI module
Loopback Server:
.. code-block:: bash
- mvn clean install -DskipTests=true -Dmaven.test.skip=true -Dmaven.javadoc.skip=true -Dadditionalparam=-Xdoclint:none
+ mvn clean install -Pq -Dadditionalparam=-Xdoclint:none
Spin up a Docker container with the database
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Dserver.port=55555
- **Browse Working Directory to your application path** ``.../cds/ms/blueprintsprocessor/application``
+ **Browse Working Directory to your application path** ``.../cds/ms/blueprintsprocessor/application``
**if path is not already specified correctly.**
**Add/replace the following in Blueprint's application-dev.properties file:**
Compilation error?
********************
-* Change Java Version to 11 or 8
+* Change Java Version to 11
.. image alignment inside tabs doesn't work
.. |imageRunConfigJava| image:: media/run_config_java.png
- :scale: 75 %
+ :width: 500pt
:align: middle
.. |imageRunConfigKt| image:: media/run_config_kt.png
- :scale: 75 %
+ :width: 500pt
:align: middle
.. |imageCreateRunConfigJava| image:: media/create_run_config_java.png
- :scale: 75 %
+ :width: 500pt
:align: middle
.. |imageCreateRunConfigKt| image:: media/create_run_config_kt.png
- :scale: 75 %
+ :width: 500pt
:align: middle
.. |imageImportProject| image:: media/import_project.png
- :scale: 75 %
+ :width: 300pt
:align: middle
.. |imageReimportMaven| image:: media/reimport_maven.png
- :scale: 75 %
+ :width: 400pt
:align: middle
.. |imageRunDebug| image:: media/run_debug.png
- :scale: 75 %
+ :width: 500pt
:align: middle
-.. |imageRunDebug| image:: media/run_debug.png
- :align: middle
- :scale: 75 %
-
.. |imageBuildLogs| image:: media/build_logs.png
+ :width: 500pt
:align: middle
- :scale: 75 %
.. |imageLogsVSC| image:: media/vsc_logs.png
+ :width: 500pt
:align: middle
- :scale: 75 %
\ No newline at end of file
Code Review / ccsdk / cds.git / commitdiff
