10 files changed, 0 insertions, 233 deletions
diff --git a/docs/microservices/blueprintsProcessorMS.rst b/docs/microservices/blueprintsProcessorMS.rst
deleted file mode 100644
index 9f13c0e5d..000000000
--- a/docs/microservices/blueprintsProcessorMS.rst
+++ /dev/null
@@ -1,87 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.
-.. Copyright (C) 2019 IBM.
-
-Blueprints Processor
-====================
-
-.. 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.
-
-Architecture:
--------------
-
-|image0|
-
-.. |image0| image:: media/blueprintprocessor.jpg
-   :width: 400pt
-
-Running Blueprints Processor Microservice Locally:
---------------------------------------------------
-
-The purpose of this page is to show how to run the Blueprints Processor microservice locally, using the docker-compose.yaml file provided in the project.
-
-Check out the CDS' code:
-
-Check out the latest code from Gerrit: https://gerrit.onap.org/r/#/admin/projects/ccsdk/cds
-
-Build CDS locally:
-In the checked out directory, type
-
-.. code-block:: none
-
-   mvn clean install -Pq -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.
-
-The first step is to create any custom image needed, by building the distribution module.  From the CDS home directory (where the code was checked out), navigate to the module:
-
-.. 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.
-
-
-To verify the logs generated by docker-composer, type:
-
-.. code-block:: none
-
-   docker-compose logs -f
-
-
-Testing the environment:
-------------------------
-
-Point your browser to http://localhost:8000/api/v1/execution-service/ping (please note that the port is 8000, not 8080)
-
-To authenticate, use login user id and password.
-\ No newline at end of file
diff --git a/docs/microservices/controllerBlueprintMS.rst b/docs/microservices/controllerBlueprintMS.rst
deleted file mode 100644
index 6b9fb49a2..000000000
--- a/docs/microservices/controllerBlueprintMS.rst
+++ /dev/null
@@ -1,21 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.
-.. Copyright (C) 2019 IBM.
-
-Controller Blueprints Studio Processor
-======================================
-
-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.
-
-
-Controller Blueprint Microservices:
------------------------------------
-
-.. toctree::
-   :maxdepth: 1
-
-   dynamicapi
-   enrichment
diff --git a/docs/microservices/dynamicapi.rst b/docs/microservices/dynamicapi.rst
deleted file mode 100644
index 264dcc570..000000000
--- a/docs/microservices/dynamicapi.rst
+++ /dev/null
@@ -1,23 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-.. 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.
-
-The actionName, under the actionIdentifiers refers to the name of a Workflow (see workflow)
-
-The content of the payload is what is fully dynamic / model driven.
-
-The first top level element will always be either $actionName-request for a request or $actionName-response for a response.
-
-Then the content within this element is fully based on the workflow input and output.
-
-Here is how the a generic request and response look like.
-
-|image0|
-
-.. |image0| image:: media/dyanmicapi.jpg
-   :width: 500pt
-\ No newline at end of file
diff --git a/docs/microservices/enrichment.rst b/docs/microservices/enrichment.rst
deleted file mode 100644
index 5ddb23bb4..000000000
--- a/docs/microservices/enrichment.rst
+++ /dev/null
@@ -1,33 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0
-.. International License. http://creativecommons.org/licenses/by/4.0
-.. Copyright (C) 2019 IBM.
-
-
-Enrichment
-==========
-.. toctree::
-   :maxdepth: 1
-
-Once the base CBA zip file is done, the enrichment process will complete the design by providing all the definitions required for the self-service provisioning.
-
-The following shows 2 ways to run CBA enrichment
-
-REST API request:
------------------
-|image0|
-
-
-CDS UI:
--------
-|image1|
-
-|image2|
-
-.. |image0| image:: media/Enrichment-REST.png
-   :width: 500pt
-
-.. |image1| image:: media/Enrichment-UI1.png
-   :width: 500pt
-
-.. |image2| image:: media/Enrichment-UI2.png
-   :width: 500pt
-\ No newline at end of file
diff --git a/docs/microservices/media/Enrichment-REST.png b/docs/microservices/media/Enrichment-REST.png
deleted file mode 100644
index 005f7960b..000000000
--- a/docs/microservices/media/Enrichment-REST.png
+++ /dev/null
diff --git a/docs/microservices/media/Enrichment-UI1.png b/docs/microservices/media/Enrichment-UI1.png
deleted file mode 100644
index 082af6128..000000000
--- a/docs/microservices/media/Enrichment-UI1.png
+++ /dev/null
diff --git a/docs/microservices/media/Enrichment-UI2.png b/docs/microservices/media/Enrichment-UI2.png
deleted file mode 100644
index 90be708b5..000000000
--- a/docs/microservices/media/Enrichment-UI2.png
+++ /dev/null
diff --git a/docs/microservices/media/blueprintprocessor.jpg b/docs/microservices/media/blueprintprocessor.jpg
deleted file mode 100644
index 429876a13..000000000
--- a/docs/microservices/media/blueprintprocessor.jpg
+++ /dev/null
diff --git a/docs/microservices/media/dyanmicapi.jpg b/docs/microservices/media/dyanmicapi.jpg
deleted file mode 100644
index 5cc1ae176..000000000
--- a/docs/microservices/media/dyanmicapi.jpg
+++ /dev/null
diff --git a/docs/microservices/workflow.rst b/docs/microservices/workflow.rst
deleted file mode 100644
index 5a564870c..000000000
--- a/docs/microservices/workflow.rst
+++ /dev/null
@@ -1,69 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0
-.. International License. http://creativecommons.org/licenses/by/4.0
-.. Copyright (C) 2019 IBM.
-
-Workflow
-========
-A workflow defines an overall action to be taken on the service, hence is an entry-point for the run-time execution of the CBA package.
-
-A workflow also defines inputs and outputs that will defined the payload contract of the request and response (see Dynamic API)
-
-A workflow can be composed of one or multiple sub-actions to execute.
-
-A CBA package can have as many workflows as needed.
-
-
-Single action
--------------
-The workflow is directly backed by a node_template of type tosca.nodes.Component
-
-
-Multiple sub-actions
---------------------
-The workflow is backed by Directed Graph engine, node_template of type dg-generic, and are imperative workflows.
-
-A DG used as workflow for CDS is composed of multiple execute nodes; each individual execute node refers to a plugin, that is a node_template of type tosca.nodes.Component.
-
-Below the properties of a workflow:
-
-
-Workflow Example
-----------------
-.. code-block:: json
-
-   {
-     "workflow": {
-       "resource-assignment": {                                <- workflow-name
-         "inputs": {
-           "vnf-id": {                                         <- static inputs
-             "required": true,
-             "type": "string"
-           },
-           "resource-assignment-properties": {                 <- dynamic inputs
-             "required": true,
-             "type": "dt-resource-assignment-properties"
-           }
-         },
-         "steps": {
-           "call-resource-assignment": {                       <- step-name
-             "description": "Resource Assignment Workflow",
-             "target": "resource-assignment-process"           <- node_template targeted by the step
-           }
-         },
-         "outputs": {
-           "template-properties": {                            <- output
-             "type": "json",                                   <- complex type
-             "value": {
-               "get_attribute": [                              <- uses expression to retrieve attribute from context
-                 "resource-assignment",
-                 "assignment-params"
-               ]
-             }
-           }
-         }
-       }
-     }
-   }
-
-
-TOSCA definition: http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html#_Toc494454203