72 files changed, 748 insertions, 2528 deletions

diff --git a/docs/index.rst b/docs/index.rst
index 8d3496cd..a3ed0e03 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -21,7 +21,7 @@ Data Collection, Analytics, and Events (DCAE)
    ./sections/tls_enablement.rst
    ./sections/sdk/index.rst
    ./sections/configuration.rst
-   ./sections/components/component-development.rst
+   ./sections/design-components/index-onboarding.rst
    ./sections/services/serviceindex.rst
    ./sections/release-notes.rst  
  
diff --git a/docs/sections/DCAE-MOD/mod-index.rst b/docs/sections/DCAE-MOD/mod-index.rst
deleted file mode 100644
index 8e72fb36..00000000
--- a/docs/sections/DCAE-MOD/mod-index.rst
+++ /dev/null
@@ -1,14 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-
-DCAE Model Onboarding and Design (DCAE MOD)
-===========================================
-
-.. toctree::
-   :maxdepth: 1   
-   
-   ./DCAE-MOD-Intro.rst
-   ./DCAE-MOD-Architecture.rst
-   ./Roles.rst
-   ./DCAE-MOD-User-Guide.rst
-   ./Glossary.rst
\ No newline at end of file
diff --git a/docs/sections/apis/deployment-handler.rst b/docs/sections/apis/deployment-handler.rst
index ab4c0c5c..a35bc8bd 100644
--- a/docs/sections/apis/deployment-handler.rst
+++ b/docs/sections/apis/deployment-handler.rst
@@ -1,7 +1,7 @@
 .. This work is licensed under a
    Creative Commons Attribution 4.0 International License.
 
-deployment-handler
+Deployment-Handler
 ==================
 
 .. toctree::
diff --git a/docs/sections/components/architecture/pieces.rst b/docs/sections/components/architecture/pieces.rst
deleted file mode 100755
index 9e57c02b..00000000
--- a/docs/sections/components/architecture/pieces.rst
+++ /dev/null
@@ -1,11 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.

-.. http://creativecommons.org/licenses/by/4.0

-

-Platform technologies

-=====================

-

--  `Cloudify <http://getcloudify.org/>`__

--  `Consul <https://www.consul.io/>`__

--  `Docker <https://www.docker.com/>`__

--  `CDAP <https://cdap.io/>`__

--  `Registrator <https://github.com/gliderlabs/registrator>`__

diff --git a/docs/sections/components/architecture/service-discovery.rst b/docs/sections/components/architecture/service-discovery.rst
deleted file mode 100755
index 315f4520..00000000
--- a/docs/sections/components/architecture/service-discovery.rst
+++ /dev/null
@@ -1,36 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.

-.. http://creativecommons.org/licenses/by/4.0

-

-Service Discovery

-=================

-

-Service discovery is an architecture pattern used for components

-(micro-services) to locate each other. The DCAE platform uses

-`server-side

-discovery <http://microservices.io/patterns/server-side-discovery.html>`__

-and is using `Consul <https://www.consul.io/>`__ as the service registry

-solution.

-

-Service Registration

---------------------

-

-All components are required to register with Consul in order to be

-discovered. There are two methods of registration: self and 3rd party.

-The DCAE platform uses 3rd party registration which means components

-don’t actually make the registration calls but defers that

-responsibility to a platform service.

-

-Implementation for Docker

-~~~~~~~~~~~~~~~~~~~~~~~~~

-

-`Registrator <http://gliderlabs.com/registrator/latest/>`__ is an open

-source application that is responsible for registering all components

-that run as Docker containers. Registrator watches the local Docker

-engine’s activity log and will register and unregister a Docker

-container when the container is started and stopped.

-

-Implementation for CDAP

-~~~~~~~~~~~~~~~~~~~~~~~

-

-The CDAP broker is a REST web service that is responsible for

-registering all components that run as CDAP applications.

diff --git a/docs/sections/components/blueprint_generator.rst b/docs/sections/components/blueprint_generator.rst
deleted file mode 100644
index 3a014ea3..00000000
--- a/docs/sections/components/blueprint_generator.rst
+++ /dev/null
@@ -1,77 +0,0 @@
-
-Blueprint Generator (DCAE)
-==========================
-
-What is the Blueprint Generator?
-++++++++++++++++++++++++++++++++
-The blueprint generator is a java rewrite of the tosca lab python tool. The point of this tool is to be able to take a component spec for a given micro-service and translate that component spec into a blueprint yaml file that can be used during deployment.
-
-
-Steps to run the blueprint generator:
-+++++++++++++++++++++++++++++++++++++
-
-1. Download the jar file from Nexus by clicking `here <https://nexus.onap.org/service/local/repositories/releases/content/org/onap/dcaegen2/platform/mod/blueprint-generator/1.3.1/blueprint-generator-1.3.1-executable.jar>`_ or running
-    ``https://nexus.onap.org/service/local/repositories/releases/content/org/onap/dcaegen2/platform/mod/blueprint-generator/1.3.1/blueprint-generator-1.3.1-executable.jar``
-
-2. To execute the application, run the following command: 
-    ``java -jar blueprint-generator-1.3.1-executable.jar blueprint``
-
-3. This execution will provide the help, as you have not provided the required flags.
-
-4. When ready you can run the program again except with the required flags.
-
-5. OPTIONS:
-    -p: The path to where the final blueprint yaml file will be created (required)
-
-    -i: The path to the JSON spec file (required)
-
-    -n: Name of the blueprint (optional)
-
-    -t: the path to the import yaml file (optional)
-    
-    -d: If this flag is present the bp generator will be created with dmaap plugin (optional)
-
-    -o: This flag will create a service component override for your deployment equal to the value you put (optional)
-
-6. An example running this program would look like this:
-    ``java -jar blueprint-generator-1.3.1-executable.jar -p blueprint_output -i ComponentSpecs/TestComponentSpec.json -n TestAppBlueprint``
-
-
-Extra information
------------------
-
-1. The component spec must be of the same format as stated in the onap `readthedocs <https://onap.readthedocs.io/en/latest/submodules/dcaegen2.git/docs/sections/components/component-specification/common-specification.html#working-with-component-specs>`_ page
-
-2. If the tag says required then the program will not run without those tags being there
-
-3. If the tag says optional then it is not necessary to run the program with those tags
-
-4. If you do not add a -n tag the blueprint name will default to what it is in the component spec
-
-5. If the directory you specified in the -p tag does not already exist the directory will be created for you
-
-6. The -t flag will override the default imports set for the blueprints. To see an example of how the import yaml file should be structured see the testImports.yaml file under the folder TestCases
-
-
-How to create policy models:
-+++++++++++++++++++++++++++++++++++++
-
-1. Policy model creation can be done with the same jar as downloaded for the blueprint generation.
-
-2. Run the same command as the blueprint generator except replace the ``blueprint`` positional with ``policy``
-
-3. Example command:
-    ``java -jar blueprint-generator-1.3.1-executable.jar policy``
-
-4. Options:
-
-   -i: The path to the JSON spec file (required)
-
-   -p: The Output path for all of the models (required)
-
-Extra information
------------------
-
-1. Not all component specs will be able to create policy models
-
-2. Multiple policy model files may be create from a single component spec
\ No newline at end of file
diff --git a/docs/sections/components/component-development.rst b/docs/sections/components/component-development.rst
deleted file mode 100644
index 196e7a09..00000000
--- a/docs/sections/components/component-development.rst
+++ /dev/null
@@ -1,22 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-
-Onboarding Pre-requisite (Service Component)
-============================================
-
-.. toctree::
-   :maxdepth: 1
-
-   ./intro.rst
-   ../DCAE-MOD/mod-index.rst
-   ./architecture/pieces.rst
-   ./architecture/service-discovery.rst
-   ./architecture/blueprint_generator.rst
-   ./requirements-guidelines.rst
-   ./component-specification/component-specification.rst
-   ./component-json-schema.rst
-   ./data-formats.rst
-   ./dcae-cli/dcae-cli-tool.rst
-   ./glossary.rst
-   
-
diff --git a/docs/sections/components/component-specification/cdap-specification.rst b/docs/sections/components/component-specification/cdap-specification.rst
deleted file mode 100755
index 2b26442a..00000000
--- a/docs/sections/components/component-specification/cdap-specification.rst
+++ /dev/null
@@ -1,208 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.

-.. http://creativecommons.org/licenses/by/4.0

-

-.. _cdap-specification:

-

-Component specification (CDAP)

-==============================

-

-The CDAP component specification contains the following groups of

-information. Many of these are common to both CDAP and Docker components

-and are therefore described in the common specification.

-

--  :any:`Metadata <metadata>`

--  :any:`Interfaces <interfaces>` including the

-   associated :any:`Data Formats <data-formats>`

--  :any:`Parameters <parameters>` - for specifying parameters in your

-   AppConfig, AppPreferences, and ProgramPreferences to the Designer and

-   Policy. This of course is CDAP-specific and is described below.

--  :any:`Auxiliary Details <auxiliary-details>`

--  :any:`List of artifacts <artifacts>`

-

-Current Limitations and TODOs

------------------------------

-

--  The integration of DMD is likely to significantly change the

-   :any:`Interfaces <interfaces>` section in this specification.

-

-.. _parameters:

-

-Parameters

-----------

-

-There is a ``parameters`` section in your component specification. This

-section contains three optional keys: `app_config <#appconfig>`__,

-`app_preferences <#apppreferences>`__, and

-`program_preferences <#programpreferences>`__:

-

-::

-

-    "parameters" : {

-        "app_config" : [ ...],               

-        "app_preferences" : [ ...],          

-        "program_preferences" : [...]

-        // any additional keys are ignored

-    }

-

--  Each section details the parameters that are a part of each of these

-   CDAP constructs (see below).

--  All such parameters will be exposed to the designer and to policy for

-   override.

--  These parameters should have default values specified by the

-   component developer where necessary, i.e., parameters that *must*

-   come from the designer/policy should not have defaults.

--  All of these keys are optional because not every CDAP application

-   uses preferences and not every application uses the AppConfig.

-   However, you should specify at least one, or else your application

-   will have no parameters exposed to policy or to the DCAE designer,

-   which means it would be non-configurable.

--  Despite the AppConfig being optional to *specify* in the case that

-   you have no parameters in your AppConfig, it is *required for

-   processing* in your application. That is because the DCAE platform

-   will place important information into your AppConfig as discussed

-   below.

-

-Parameter

-~~~~~~~~~

-

-The following CDAP specific definitions use ``param1`` to refer to the

-common parameter layout in

-:any:`Parameter <parameters>`

-

-AppConfig

-~~~~~~~~~

-

-The ``app_config`` key refers to the `CDAP AppConfig <http://docs.cask.co/cdap/current/en/reference-manual/http-restful-api/configuration.html>`_.

-It is expected to be a JSON:

-

-::

-

-    "app_config" : [ // list of JSON

-        param1,      // common parameter layout

-        ...

-    ]

-

-Unfortunately, at the time of writing, the AppConfig is a Java map of

-``string:string``, which means you cannot have more complex structures

-(than string) as any value in your AppConfig. However, there is a way to

-bypass this constraint: you can pass a JSON by encoding the JSON as a

-string. E.g., the ``json.dumps()`` and it’s converse ``loads`` methods

-in Python:

-

-::

-

-    >>> import json

-    >>> json.dumps({"foo" : "bar"})     # This is a real JSON

-    '{"foo": "bar"}'                    # It is now a string: pass this in as your parameter value

-    >>> json.loads('{"foo": "bar"}')    # Do the equivelent of this in your application

-    {u'foo': u'bar'}                    # ...and you'll get back a real JSON 

-    >>>

-

-The final AppConfig (after the designer and policy override parameter

-values) is passed into CDAP’s AppConfig API when starting the

-application.

-

-

-AppPreferences

-~~~~~~~~~~~~~~

-

-In addition to the CDAP AppConfig, the platform supports `Application Preferences <http://docs.cask.co/cdap/current/en/reference-manual/http-restful-api/preferences.html#set-preferences>`_.

-The format of the ``app_preferences`` value is the same as the above:

-

-::

-

-    "app_preferences" : [   // list of JSON

-        param1,      // common parameter layout

-        ...

-    ]

-

-The final Application Preferences JSON (after the designer and policy

-override parameter values) is passed into CDAP’s Preferences API when

-starting your application.

-

-

-ProgramPreferences

-~~~~~~~~~~~~~~~~~~

-

-Preferences can also be specified `per program <http://docs.cask.co/cdap/current/en/reference-manual/http-restful-api/lifecycle.html#program-lifecycle>`_

-in CDAP. This key’s value is a list of JSON with the following format:

-

-::

-

-    "program_preferences" : [                // note: this is a list of JSON 

-        {

-          "program_id" :   "program name 1",  // the name of this CDAP program

-          "program_type" : "e.g., flows",     // "must be one of flows, mapreduce, schedules, spark, workflows, workers, or services",

-          "program_pref" : [                  // list of JSON

-          param1,      // common parameter layout

-              ...

-          ]

-        },

-        // repeat for each program that receives a program_preferences JSON 

-    ]

-

-Each ``program_pref`` JSON is passed into the CDAP API as the preference

-for ``program_id``.

-

-NOTE: for CDAP, this section is very likely to change when DMD is

-available. The *future* vision is

-that you would publish your data as a series of files on HDFS, and DMD

-will pick them up and send them to the appropriate DMaaP feeds or

-directly when needed.

-

-.. _auxiliary-details:

-

-Auxiliary Details

------------------

-

-*auxiliary* contains details about CDAP specific parameters.

-

-+----------------------+----------------------+----------------------+

-| Property Name        | Type                 | Description          |

-+======================+======================+======================+

-| streamname           | string               | *Required*.          |

-+----------------------+----------------------+----------------------+

-| artifact_name        | string               |                      |

-+----------------------+----------------------+----------------------+

-| artifact_version     | string               | the version of your  |

-|                      |                      | CDAP JAR artifact    |

-+----------------------+----------------------+----------------------+

-| namespace            | string               | the CDAP namespace   |

-|                      |                      | to deploy into,      |

-|                      |                      | default is ‘default’ |

-+----------------------+----------------------+----------------------+

-| programs             | array                | contains each CDAP   |

-|                      |                      | entity represented   |

-|                      |                      | in the artifact      |

-+----------------------+----------------------+----------------------+

-| program_type         | string               | CDAP entity (eg      |

-|                      |                      | “flows”)             |

-+----------------------+----------------------+----------------------+

-| program_id           | string               | name of CDAP entity  |

-|                      |                      | (eg “WhoFlow”)       |

-+----------------------+----------------------+----------------------+

-

-Example:

-

-.. code:: json

-

-    "auxiliary": {

-        "streamname" : "who",

-        "artifact_name" : "HelloWorld",

-        "artifact_version" : "3.4.3",

-        "namespace" : "hw",

-        "programs" : [

-                        {"program_type" : "flows", "program_id" : "WhoFlow"}, 

-                        {"program_type" : "services", "program_id" : "Greeting"},

-                        ...

-                      ],

-    }

-

-The ``programs`` key is identical to the ``program_preferences`` key

-discussed `above <#programpreferences>`__ except:

-

--  each JSON in the list does not contain ``program_pref``

--  this is required! You must include all of your programs in this, as

-   it is used to start each program as well as for DCAE to perform

-   periodic healthchecks on your application. Don’t forget about your

-   services; they are programs too.

diff --git a/docs/sections/components/component-type-cdap.rst b/docs/sections/components/component-type-cdap.rst
deleted file mode 100755
index f2dce6c5..00000000
--- a/docs/sections/components/component-type-cdap.rst
+++ /dev/null
@@ -1,87 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.

-.. http://creativecommons.org/licenses/by/4.0

-

-.. _cdap-requirements:

-

-CDAP Component Requirements

-===========================

-

-This page contains information about CDAP app development in DCAE.

-

-Uploading your Jar File

------------------------

-

-The DCAE component specification has you input your ``jar_url``, the URL

-on Nexus to your Jar file. This DCAE controller deploys out of Nexus.

-You can upload your jar(s) using the following command, replacing NAME:

-

-::

-

-    curl -v --user 'user:password' http://YOUR_NEXUS_RAW_REPO/NAME.jar --upload-file NAME.jar

-

-During the CLI Tool Usage, in your spec, supply

-``http://YOUR_NEXUS_RAW_REPO/NAME.jar`` as the JAR artifact URL.

-

-Policy Reconfiguration

-----------------------

-

-We support reconfiguration of both AppConfig and AppPreferences.

-

-For AppConfig, we support CDAPs “update” API to `reconfigure an application <http://docs.cask.co/cdap/current/en/reference-manual/http-restful-api/lifecycle.html#update-an-application%7D%7D>`_.

-

-For AppPreferences, we:

-

-1. Stop your programs

-

-2. Set the new preferences

-

-3. Start your programs

-

-At the time of writing, there is no way to update a CDAP application’s

-AppConfig or AppPreferences, without a restart, *and notify* the

-application. The latter is a future promised feature by CASK—the ability

-to update preferences and inform the application that something is

-changed (so it repulls). As CDAP currently stands however, given the

-above, if you are building a stateful application, you must persist your

-state often (e.g., to a CDAP dataset), as you may be restarted at any

-time with an updated configuration, or stopped&started at any time with

-updated preferences.

-

-Metrics

--------

-

-Metrics are pulled from your CDAP application on a periodic basis and

-(in the future: pushed to a central DCAE metric store, currently: just

-dropped). For this to be useful, your application should provide `metrics <http://docs.cask.co/cdap/current/en/admin-manual/operations/metrics.html>`_.

-While nothing in the DCAE runtime enforces that your CDAP application

-tracks metrics, your metrics (or lack thereof) will be visible in the

-DCAE dashboard and to operations.

-

-.. _dmaap-abstraction:

-

-Future DMaaP abstraction

-------------------------

-

-Shown below is our *vision* for how DMaaP is abstracted from component

-developers:

-

-.. figure:: ./images/dmdvision.png

-

-Today, this is a vision; it is not in place. Today, each CDAP app is

-built with built in assumptions about where they are getting their data

-from. Some CDAP apps have the built in assumption of a UEB feed. Some

-MR. Some DR. This becomes very difficult to orchestrate when each app in

-the catalog has built in data assumptions.

-

-The goal of this vision is to *decouple* the data plane from the

-analytics plane. Analytics should be agnostic to *how* they are

-receiving their data beyond “filesystem” or “HTTP”. Analytics developers

-shouldn’t have to worry about the data plane, that should be taken care

-of by the platform. They should be spending their time on the problem at

-hand—the analytic.

-

-This also allows each CDAP application to have a standard set of

-interfaces: HTTP and HDFS: 

-

-.. figure::  ./images/io.png

-

diff --git a/docs/sections/components/component-type-docker.rst b/docs/sections/components/component-type-docker.rst
deleted file mode 100755
index 90742453..00000000
--- a/docs/sections/components/component-type-docker.rst
+++ /dev/null
@@ -1,465 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.

-.. http://creativecommons.org/licenses/by/4.0

-

-.. _docker-requirements:

-

-Docker Component Requirements

-=============================

-

-Overview

---------

-

-Component developers are required to provide artifacts for the platform

-to be able to deploy your component including:

-

--  `Component specification <docker-specification>`

--  `One or more Data Formats <data-formats>` \*unless they already exist

--  `Docker image <#docker-on-the-platform>`__

-

-In addition, components will have to be enhanced to be compliant with

-the DCAE platform in order to correctly be deployed and be managed. This

-page will discuss the changes which are grouped into the following

-categories:

-

--  `Service Registration <#service-registration>`__

--  `Configuration management on the new platform <#configuration-management>`__

--  `Docker on the Platform <#docker-on-the-platform>`__

--  `Operational concerns <#operational-concerns>`__

-

-Additional considerations are:

-

--  `Policy Reconfiguration <#policy-reconfiguration>`__

-

-To help component developers to make and to test the changes needed to

-have components run on the platform, a command-line tool called

-:doc:`dcae-cli <dcae-cli/quickstart>` is provided by the platform team.

-(Testing withing the dcae_cli tool is not yet available for Policy).

-

-Service Registration

---------------------

-

-Every :doc:`Docker component is registered <../components/architecture/service-discovery>` with the platform’s

-service discovery layer. Docker components are not expected to make the

-explicit make registration calls because that is done by through a

-platform 3rd party registration service. A couple things are needed from

-component developers in order for this registration to occur

-successfully:

-

-1. Docker images must be created from a Dockerfile that has an

-   `EXPOSE <https://docs.docker.com/engine/reference/builder/#/expose>`__

-   instruction. This applies to components that listen on a port.

-2. Component healthcheck details must be provided in the Docker

-   auxiliary component specification

-

-Expose port

-~~~~~~~~~~~

-

-Components that listen on a specific port must explicitly declare in

-their Dockerfile that port using the ``EXPOSE`` instruction before

-building the image. Warning! At the current time, you can not expose

-multiple ports in your Dockerfile or registration *will not work*

-correctly. Warning! Be sure to choose a port that is available. This may

-vary by environment.

-

-Health check

-~~~~~~~~~~~~

-

-Component developers are required to provide a way for the platform to

-periodically check the health of their running components. The platform

-uses Consul to perform these periodic calls. Consul provides different

-types of `check

-definitions <https://www.consul.io/docs/agent/checks.html>`__. The

-details of the definition used by your component is to be provided

-through the :any:`Docker auxiliary specification <docker-auxiliary-details>`.

-

-Configuration Management

-------------------------

-

-All configuration for a component is stored in CONSUL under the

-components uniquely generated name which is provided by the environment

-variable ``HOSTNAME`` as well as ``SERVICE_NAME``. It is then made

-available to the component via a remote HTTP service call to CONFIG

-BINDING SERVICE.

-

-The main entry in CONSUL for the component contains its

-``generated application configuration``. This is based on the submitted

-component specification, and consists of the ``interfaces`` (streams and

-services/calls) and ``parameters`` sections. Other entries may exist as

-well, under specific keys, such as :dmaap . Each key represents a

-specific type of information and is also available to the component by

-calling CONFIG BINDING SERVICE. More on this below.

-

-Components are required to pull their

-``generated application configuration`` at application startup. The

-component must provide an initialization script that retrieves the

-application configuration and reference that script in its Dockerfile.

-Other calls can be made to CONFIG BINDING SERVICE to retrieve DMaaP,

-or Policy Reconfiguration (not yet supported).

-

-You can see more details on the generated application configuration

-:any:`here <dcae-cli-view-the-platform>`

-

-.. _config_binding_service:

-

-Config Binding Service

-~~~~~~~~~~~~~~~~~~~~~~

-

-The config binding service is a platform HTTP service that is

-responsible for providing clients with its fully resolve configuration

-JSON at startup, and also other configurations objects 

-when requested.

-

-At runtime, components should make an HTTP GET on:

-

-::

-

-    <config binding service hostname>:<port>/service_component/NAME

-

-For Docker components, NAME should be set to ``HOSTNAME``, which is

-provided as an ENV variable to the container.

-

-The binding service integrates with the streams and services section of

-the component specification. For example, if you specify that you call a

-service:

-

-::

-

-    "services": {

-        "calls": [{

-            "config_key": "vnf-db",

-            "request": {

-                "format": "dcae.vnf.meta",

-                "version": "1.0.0"

-                },

-            "response": {

-                "format": "dcae.vnf.kpi",

-                "version": "1.0.0"

-                }

-        }],

-    ...

-    }

-

-Then the config binding service will find all available IP addresses of

-services meeting the containers needs, and provide them to the container

-under your ``config_key``:

-

-::

-

-    // your configuration

-    {

-        "vbf-db" :                 // see above 

-            [IP:Port1, IP:Port2,…] // all of these meet your needs, choose one.

-    }

-

-Regarding ``<config binding service hostname>:<port>``, there is DNS

-work going on to make this resolvable in a convenient way inside of your

-container. However, currently you will be given a name as an ENV

-variable, ``CONFIG_BINDING_SERVICE``, and you will need to query

-Consul’s service discovery to get

-``<config binding service hostname>:<port>``.

-

-Generated Application Configuration

-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-

-The DCAE platform uses the component specification to generate the

-component’s application configuration provided at deployment time. The

-component developer should expect to use this configuration JSON in the

-component.

-

-Pro-tip: As you build the component specification, use the :any:`dcae-cli dev command <dcae-cli-view-the-platform>`

-to see what the resulting application configuration will look like.

-

-For both Docker and CDAP, when the component is deployed, any

-``streams`` and ``services/calls`` specified, will be injected into the

-configuration under the following well known structure, along with all

-``parameters``. (``services/provides`` is not passed in to the

-application config). Your component is required to parse this

-information if it has any DMaaP connections or interfaces with another

-DCAE component.

-

-This is best served by an example.

-

-The following component spec snippet (from String Matching):

-

-::

-

-    "streams":{  

-        "subscribes": [{

-          "format": "VES_specification",  

-          "version": "4.27.2",    

-          "type": "message_router",

-          "config_key" : "mr_input"

-        }],

-        "publishes": [{

-          "format": "VES_specification",  

-          "version": "4.27.2",    

-          "config_key": "mr_output",

-          "type": "message_router"

-         }]

-      },

-      "services":{  

-        "calls": [{

-          "config_key" : "aai_broker_handle",

-          "verb": "GET",

-          "request": {

-            "format": "get_with_query_params",

-            "version": "1.0.0"

-          },

-          "response": {

-            "format": "aai_broker_response",

-            "version": "3.0.0"

-          } 

-        }],

-        "provides": []

-      },

-

-Will result in the following top level keys in the configuration (for

-CDAP, this will be under AppConfig)

-

-::

-

-       "streams_publishes":{  

-          "mr_output":{                // notice the config key above

-             "aaf_password":"XXX",

-             "type":"message_router",

-             "dmaap_info":{  

-                "client_role": null,

-                "client_id": null,

-                "location": null,

-                "topic_url":"https://YOUR_HOST:3905/events/com.att.dcae.dmaap.FTL2.DCAE-CL-EVENT" // just an example

-             },

-             "aaf_username":"XXX"

-          }

-       },

-       "streams_subscribes":{  

-          "mr_input":{                 // notice the config key above

-             "aaf_password":"XXX",

-             "type":"message_router",

-             "dmaap_info":{  

-                "client_role": null,

-                "client_id": null,

-                "location": null,

-                "topic_url":"https://YOUR_HOST:3905/events/com.att.dcae.dmaap.FTL2.TerrysStringMatchingTest" // just an example

-             },

-             "aaf_username":"XXX"

-          }

-       },

-       "services_calls":{  

-          "aai_broker_handle":[        // notice the config key above

-             "135.205.226.128:32768"   // based on deployment time, just an example

-          ]

-       }

-

-These keys will always be populated whether they are empty or not. So

-the minimum configuration you will get, (in the case of a component that

-provides an HTTP service, doesn’t call any services, and has no streams,

-is:

-

-::

-

-        "streams_publishes":{},

-        "streams_subscribes":{},

-        "services_calls":{}

-

-Thus your component should expect these well-known top level keys.

-

-

-DMaaP

-~~~~~

-

-Components can be publishers or subscribers to either message router

-topics or data router feeds. This is defined in the component

-specification under the ``streams`` section where you can specify

-whether your component is expected to subscribe or to publish to a

-:any:`message router <message-router>`

-topic or to a :any:`data router <data-router>`

-feed. Given a composition with components that use DMaaP, the platform

-will provision the topic or feed and provide the necessary :doc:`connection

-details <./component-specification/dmaap-connection-objects>`

-at runtime for each DMaaP dependent component. These connection details

-are provided through your application’s generated configuration.

-

-In order to test DMaaP connections in onboarding, the developer

-(currently) must provision all test topics and feeds manually and

-provide the :any:`dcae-cli with the connection details <dcae-cli-walkthrough-dmaap-testing>` when deploying your

-application.

-

-Even thought the DMaaP connection information is included in the

-generated application configuration, it may be obtained by doing a call

-as in this example:

-

-::

-

-    curl http://<config binding service>:<port>/dmaap/jm416b.d345ada1-cc31-4121-a741-9007b9f64808.1-0-1.dcae-collectors-cli-pm

-

-This would return the following:

-

-::

-

-    {"cli_gamma_cisco_pm_config_stat": 

-        {

-        "publish_url": "https://YOUR_HOST/publish/1362", 

-        "username": "mtl5-0", 

-        "log_url": null, 

-        "location": "mtl5-0", 

-        "password": "i5qji048hdm2e38f0bg872tnqd", 

-        "publisher_id": "1234"

-        }

-    }

-

-Policy Reconfiguration

-~~~~~~~~~~~~~~~~~~~~~~

-

-*(not yet supported)*

-

-Components must provide a way to receive policy reconfiguration, that

-is, configuration parameters that have been updated via the Policy UI.

-The component developer provides a docker script (defined in the :any:`Docker

-auxiliary specification <docker-auxiliary-details>`)

-that will be triggered when this occurs.

-

-Docker on the platform

-----------------------

-

-Images

-~~~~~~

-

-Docker images must be pushed to the environment specific Nexus

-repository. This requires tagging your build with the full name of you

-image which includes the Nexus repository name.

-

-Use the Docker command-line to

-`tag <https://docs.docker.com/engine/reference/commandline/tag/>`__ your

-Docker image where the *target image* must contain the registry host

-name and port.

-

-For example, an application called yourapp has been tagged for an example

-Nexus registry:

-

-::

-

-    YOUR_NEXUS_DOCKER_REGISTRY/yourapp                                                 0.4.0               154cc382df61        7 weeks ago         710.5 MB

-    yourapp                                                                                    0.4.0               154cc382df61        7 weeks ago         710.5 MB

-

-The solutioning environment’s Nexus host for the Docker registry is

-``YOUR_NEXSUS_HOST:18443``. You must run

-``docker login YOUR_NEXSUS_HOST:18443`` to access the registry.

-Please contact the DCAE platform team to provide you with the

-credentials.

-

-::

-

-    docker login YOUR_NEXSUS_HOST:18443

-

-Tag your image:

-

-::

-

-    docker tag yourapp:0.4.0 YOUR_NEXSUS_HOST:18443/dcae-platform/yourapp:0.4.0

-

-Or build and tag:

-

-::

-

-    docker build -t YOUR_NEXSUS_HOST:18443/dcae-platform/yourapp:0.4.0 .

-

-After tagging, upload your image to the remote registry using the Docker

-`push

-command <https://docs.docker.com/engine/reference/commandline/push/>`__.

-Note that the registry may require a login. Use the Docker `login

-command <https://docs.docker.com/engine/reference/commandline/login/>`__

-before pushing in that case.

-

-::

-

-    docker push YOUR_NEXSUS_HOST:18443/dcae-platform/yourapp:0.4.0

-

-*NOTE* Replace ``dcae-platform`` with the group directory that is

-applicable to your image. Replace ``yourapp`` with your application’s

-name. Replace the ``0.4.0`` version with your application’s version.

-

-Dockerfile

-~~~~~~~~~~

-

-The Dockerfile must contain the name of the container’s initialization

-script. This will be called when the container is deployed, and must

-call Config Binding Service as described in `Config Binding

-Service <#config-binding-service>`__

-

-.. _dcae-cli-docker-ports:

-

-Ports

-~~~~~

-

-On the DCAE platform, Docker components are run with the

-``--publish-all`` or ``-P`` argument. This means the Docker container

-for your component will be listening on a random port and that random

-port will be mapped to the port `you exposed <#service-registration>`__.

-

-Envs

-~~~~

-

-The platform provides a set of environment variables into each Docker

-container:

-

-+----------------------------+--------------+----------------------------------------+

-| Name                       | Type         | Description                            |

-+============================+==============+========================================+

-| ``HOSTNAME``               | string       | Unique name of the component instance  |

-|                            |              | that is generated                      |

-+----------------------------+--------------+----------------------------------------+

-| ``CONSUL_HOST``            | string       | Hostname of the platform's Consul      |

-|                            |              | instance                               |

-+----------------------------+--------------+----------------------------------------+

-| ``CONFIG_BINDING_SERVICE`` | string       | Hostname of the platform's config      |

-|                            |              | binding service instance               |

-|                            |              |                                        |

-+----------------------------+--------------+----------------------------------------+

-| ``DOCKER_HOST``            | string       | Host of the target platform Docker     |

-|                            |              | host to run the container on           |

-+----------------------------+--------------+----------------------------------------+

-

-Operational Concerns

---------------------

-

-Logging

-~~~~~~~

-

-Currently the platform uses the default ``json-file`` logging driver for

-Docker. For onboarding testing, component developers can access their

-logs from their Docker containers either by running their component

-using the ``--attached`` flag or by using the ``docker logs`` command.

-The requirement is that applications must write to stdout and/or stderr.

-

-To use the ``docker logs`` command for your deployed running Docker

-container,

-

--  You must have Docker installed on your local machine

--  Have the generated name of your component. This is generated for you

-   when you execute ``dcae_cli component dev`` or

-   ``dcae_cli component run``.

--  Find the target Docker host using the ``dcae_cli profiles show``

-   command:

-

-::

-

-    $ dcae_cli profiles show solutioning

-    {

-        "cdap_broker": "cdap_broker",

-        "config_binding_service": "config_binding_service",

-        "consul_host": "YOUR_CONSUL_HOST",

-        "docker_host": "YOUR_DOCKER_HOST:2376"

-    }

-

--  Set your Docker client to point to the target Docker host:

-

-::

-

-    $ export DOCKER_HOST="tcp://YOUR_DOCKER_HOST:2376"

-

--  Use the ``docker logs`` command:

-

-::

-

-    $ docker logs <generated component name>

-

diff --git a/docs/sections/components/dcae-cli/commands.rst b/docs/sections/components/dcae-cli/commands.rst
deleted file mode 100644
index d63fb09c..00000000
--- a/docs/sections/components/dcae-cli/commands.rst
+++ /dev/null
@@ -1,590 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.

-.. http://creativecommons.org/licenses/by/4.0

-

-.. _dcae_cli_commands:

-

-dcae_cli Commands

-=================

-

-The dcae_cli tool has four command groups. Each has several

-sub-commands.

-

-``catalog``

------------

-

-The ``catalog`` command lists and shows resources (components and

-data_formats) in the ‘onboarding’ catalog (regardless of the owner). A

-resource can have a status of ``staged`` or ``published``. By default,

-only ``published`` resources are displayed. To see ``staged`` resources,

-add the –expanded argument.

-

-+------------------------------+----------------------------------------+

-| Catalog Status               | Meaning                                |

-+==============================+========================================+

-| staged                       | resource has be added                  |

-|                              | (and validated), but                   |

-|                              | is under development                   |

-+------------------------------+----------------------------------------+

-| staged                       | data_formats can only be referenced in |

-|                              | their owners component specs           |

-+------------------------------+----------------------------------------+

-| staged                       | components can only be deployed by     |

-|                              | their owners                           |

-+------------------------------+----------------------------------------+

-| published                    | resource has been                      |

-|                              | tested and can be                      |

-|                              | shared                                 |

-+------------------------------+----------------------------------------+

-|                              | published data_formats can be used in  |

-|                              | anyone's component spec                |

-+------------------------------+----------------------------------------+

-|                              | published components and be deployed by|

-|                              | anyone                                 |

-+------------------------------+----------------------------------------+

-

-::

-

-    $ dcae_cli catalog --help

-    Usage: dcae_cli catalog [OPTIONS] COMMAND [ARGS]...

-

-    Options:

-      --help  Show this message and exit.

-

-    Commands:

-      list      Lists resources in the onboarding catalog

-      show      Provides more information about resource

-

-List onboarding catalog contents

-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-

-::

-

-    $ dcae_cli catalog list

-    Components:

-    +--------------------------------+---------+--------+---------------------------------------------------------------------+--------+-----------+------------+

-    | Name                           | Version | Type   | Description                                                         | Owner  | Status    | Published  |

-    +--------------------------------+---------+--------+---------------------------------------------------------------------+--------+-----------+------------+

-    | DcaeSyslogCollector            | 2.0.0   | docker | DCAE Control Plane Syslog Collector                                 | sh1986 | published | 2017-08-04 |

-    | cdap.dmaap.spec.example        | 0.2.0   | cdap   | dmaap spec example. Not a functioning application, only for showing | tc677g | published | 2017-07-24 |

-    |                                |         |        | how to pub/sub dmaap. Pretend this is like MAP with VES in and ou.. |        |           |            |

-    | cdap.event.proc.enrich.app     | 1.0.3   | cdap   | CDAP Event Processing Enrich application                            | an4828 | published | 2017-09-20 |

-    | cdap.event.proc.map.app        | 1.0.3   | cdap   | CDAP Event Processing Map application                               | an4828 | published | 2017-09-20 |

-

-    ...

-

-    Data formats:

-    +--------------------------------------------+---------+-----------------------------------------------------------------------+--------+-----------+------------+

-    | Name                                       | Version | Description                                                           | Owner  | Status    | Published  |

-    +--------------------------------------------+---------+-----------------------------------------------------------------------+--------+-----------+------------+

-    | FOI_PM_VHSS_data_format                    | 1.0.0   | CSV pipe delimited data format for VHSS PM files                      | sr229c | published | 2017-09-05 |

-    | Map_input                                  | 1.0.0   | The input format for Mapper, that in 1707 is the UCSNMP Collector     | an4828 | published | 2017-07-18 |

-    |                                            |         | output format, but will support more formats later                    |        |           |            |

-    | Syslog Collector Parsed Json Message       | 1.0.0   | Post processed/parsed collected syslog message                        | sh1986 | published | 2017-08-04 |

-    | Syslog Collector Syslog Message Input      | 1.0.0   | The input message for the DCAE syslog collector is free/unstructured  | sh1986 | published | 2017-08-04 |

-    |                                            |         | text                                                                  |        |           |            |

-    | myapp Alert Definition                     | 1.0.0   | The format of the output event from myapp                               | an4828 | published | 2017-08-10 |

-    | VES_specification                          | 5.28.4  | VES spec for 5.4                                                      | vv770d | published | 2017-09-19 |

-

-    ...

-

-Show the contents of an item in the catalog

-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-

-::

-

-    $ dcae_cli catalog show FOI_PM_VHSS_data_format

-

-    Data format

-    -----------

-    {

-        "dataformatversion": "1.0.0", 

-        "delimitedschema": {

-            "delimiter": "|", 

-            "fields": [

-                {

-                    "description": "System ID", 

-                    "fieldtype": "string", 

-                    "name": "SYSTEM"

-                }, 

-                {

-                    "description": "Date", 

-                    "fieldtype": "string", 

-                    "name": "DATE"

-                }, 

-                {

-                    "description": "Time", 

-                    "fieldtype": "string", 

-                    "name": "TIME"

-                }, 

-

-    ...

-

-.. _dcae_cli_component_commands:

-

---------------

-

-``component``

--------------

-

-The ``component`` command is for validating (adding), listing, showing,

-verifying generated configuration, running, undeploying, and publishing

-components that YOU own.

-

-::

-

-    $ dcae_cli component --help

-    Usage: dcae_cli component [OPTIONS] COMMAND [ARGS]...

-

-    Options:

-      --help  Show this message and exit.

-

-    Commands:

-      add

-      dev       Set up component in development for...

-      list      Lists components in the onboarding catalog.

-      publish   Pushes COMPONENT to the onboarding catalog

-      run       Runs the latest version of COMPONENT.

-      show      Provides more information about COMPONENT

-      undeploy  Undeploys the latest version of COMPONENT.

-

---------------

-

-.. _dcae_cli_add_a_component:

-

-Add a Component

-~~~~~~~~~~~~~~~

-

-A component must be added to the onboarding catalog in order to be

-tested by the dcae_cli tool. The process of adding a component also

-validates it’s component specification. In order to add a component, the

-component docker image (or CDAP jar) must exist locally.

-

-Components in the onboarding catalog can be run by others, once they are

-``published.`` ``Published`` components cannot be modified or deleted.

-Rather a new version can be created instead.

-

-Validated component specs are used later to generate Tosca models and

-Cloudify Blueprints for the component, which makes them available for

-use in the SDC Tool for creating services.

-

-::

-

-    $ dcae_cli component add --help

-    Usage: dcae_cli component add [OPTIONS] COMPONENT-SPECIFICATION

-

-    Options:

-      --update  Updates a previously added component if it has not been already

-                published

-      --help    Show this message and exit.

-

-::

-

-    $ dcae_cli component add component-spec.json 

-

---------------

-

-List Components

-~~~~~~~~~~~~~~~

-

-List components in the onboarding catalog that owned by YOUR userid..

-

-::

-

-    $ dcae_cli component list

-    Active profile: solutioning

-    +-------------------------+---------+--------+---------------------------------------------------------------+--------+----------------------------+-----------+

-    | Name                    | Version | Type   | Description                                                   | Status | Modified                   | #Deployed |

-    +-------------------------+---------+--------+---------------------------------------------------------------+--------+----------------------------+-----------+

-    | cdap.helloworld.endnode | 0.8.0   | cdap   | cdap test component                                           | staged | 2017-05-23 04:14:35.588075 | 0         |

-    | sandbox.platform.yourapp| 0.5.0   | docker | Web service used as a stand-alone test DCAE service compone.. | staged | 2017-05-23 04:07:44.065610 | 0         |

-    +-------------------------+---------+--------+---------------------------------------------------------------+--------+----------------------------+-----------+

-

-The fields ``Name``, ``Version``, ``Type``, ``Description`` are

-referenced from the component specification’s ``self`` JSON. Use the

-“–deployed” argument to see more details on deployed components

-

---------------

-

-.. _dcae_cli_run_a_component:

-

-Run a Component

-~~~~~~~~~~~~~~~

-

-The ``run`` operation is to be used for running your application in its

-container remotely on the activated environment. Docker containers have

-the additional option to run locally on your development machine. If the

-component uses Dmaap, you can specify the Dmaap Connection Object as

-well. Refer to :doc:`Dmaap Connection Object <../component-specification/dmaap-connection-objects>`.

-

-When you run a component via the dcae_cli Tool, remember the blueprint

-has not been created and is not used for deployment.

-

-In order to run the component, the data formats and component must have

-been added to the onboarding catalog.

-

-**DOCKER NOTE:** Make sure the Docker image has been uploaded to the

-shared registry.

-

-A docker component can be run in either ``attached`` or ``unattached``

-mode. (Default is unattached).

-

-+------------------+---------------------------------------------------+

-| Mode             | Description                                       |

-+==================+===================================================+

-| attached         | component is run in the ‘foreground’, container   |

-|                  | logs are streamed to stdout. Ctrl-C is used to    |

-|                  | terminate the dcae_cli session.                   |

-+------------------+---------------------------------------------------+

-| unattached       | component is run in the ‘background’, container   |

-|                  | logs are viewed via ``docker logs`` command,      |

-|                  | container runs until undeployed with dcae_cli     |

-|                  | ``undeploy`` command.                             |

-+------------------+---------------------------------------------------+

-

-Run a component in attached mode:

-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

-

-::

-

-    $ dcae_cli -v component run --attached sandbox.platform.yourapp:0.5.0

-

-    DCAE.Docker | INFO | Running image 'registry.proto.server.com/dcae-rework/yourapp:0.4.0' as 'user1.b7287639-37f5-4f25-8d54-8a2087f4c8da.0-5-0.sandbox-platform-yourapp'

-    DCAE.Docker.user1.b7287639-37f5-4f25-8d54-8a2087f4c8da.0-5-0.sandbox-platform-yourapp | INFO | Consul host: yourconsulhost.com

-

-    DCAE.Docker.user1.b7287639-37f5-4f25-8d54-8a2087f4c8da.0-5-0.sandbox-platform-yourapp | INFO | service name: mh677g.b7287639-37f5-4f25-8d54-8a2087f4c8da.0-5-0.sandbox-platform-yourapp

-

-    DCAE.Docker.user1.b7287639-37f5-4f25-8d54-8a2087f4c8da.0-5-0.sandbox-platform-yourapp | INFO | Generated config: {'multiplier': 3}

-

-    DCAE.Docker.user1.b7287639-37f5-4f25-8d54-8a2087f4c8da.0-5-0.sandbox-platform-yourapp | INFO |  * Running on http://0.0.0.0:8080/ (Press CTRL+C to quit)

-

-    DCAE.Docker.user1.b7287639-37f5-4f25-8d54-8a2087f4c8da.0-5-0.sandbox-platform-yourapp | INFO | 127.0.0.1 - - [24/May/2017 03:37:57] "GET /health HTTP/1.1" 200 -

-

-    DCAE.Docker.user1.b7287639-37f5-4f25-8d54-8a2087f4c8da.0-5-0.sandbox-platform-yourapp | INFO | 127.0.0.1 - - [24/May/2017 03:38:12] "GET /health HTTP/1.1" 200 -

-

-Hit Ctrl-C to terminate session.

-

-::

-

-    ^CDCAE.Docker | INFO | Stopping container 'user1.b7287639-37f5-4f25-8d54-8a2087f4c8da.0-5-0.sandbox-platform-yourapp' and cleaning up...

-

-Run a component in unattached mode:

-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

-

-::

-

-    $ dcae_cli -v component run sandbox.platform.yourapp:0.5.0

-    DCAE.Docker | INFO | Running image 'registry.proto.server.com/dcae-rework/yourapp:0.4.0' as 'user1.4811da0e-08d5-429f-93bf-bf6814924577.0-5-0.sandbox-platform-yourapp'

-    DCAE.Run | INFO | Deployed /user1.4811da0e-08d5-429f-93bf-bf6814924577.0-5-0.sandbox-platform-yourapp

-

-**NOTE** You must undeploy this component when finished testing. This is

-important to conserve resources in the environment.

-

-Run a component that subscribes to Dmaap MR or DR

-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

-

-::

-

-    $ dcae_cli -v component run --attached --dmaap-file $dmaap-connection-file sandbox.platform.yourapp:0.5.0 

-

---------------

-

-Undeploy a Component

-~~~~~~~~~~~~~~~~~~~~

-

-The ``undeploy`` command is used to undeploy any instance of a specified

-component/version that you have deployed. This includes cleaning up the

-configuration.

-

-::

-

-    $ dcae_cli component undeploy sandbox.platform.yourapp:0.5.0

-    DCAE.Undeploy | WARNING | Undeploying components: 1

-    DCAE.Undeploy | WARNING | Undeployed components: 1

-

---------------

-

-Publish a component

-~~~~~~~~~~~~~~~~~~~

-

-| Once a component has been tested, it should be published in the

-  onboarding catalog using the ``publish`` sub-command .

-| Publishing will change the status of the component (from ``staged`` to

-  ``published``), indicating that it has been tested, and making it

-  accessible for other developers to use.

-

-**Note** Before a component can be published, all data_formats that it

-references must be published.

-

-::

-

-    dcae_cli component publish sandbox.platform.yourapp:0.5.0

-

---------------

-

-Show a Component

-~~~~~~~~~~~~~~~~

-

-This will print out the contents of a component and is useful to copy a

-component spec.

-

-::

-

-    $ dcae_cli component show

-

---------------

-

-.. _dcae-cli-run-the-dev-command:

-

-Run the ``dev`` command

-~~~~~~~~~~~~~~~~~~~~~~~

-

-The ``dev`` command is used as part of a process to see the platform

-generated configuration. It established the environment variables and is

-best explained

-:any:`here <dcae-cli-view-the-platform>`.

-

-::

-

-    $ dcae_cli component dev component-spec.json

-    Ready for component development

-

---------------

-

-.. _dcae_cli_data_format:

-

-``data_format``

----------------

-

-The ``data_format`` command is for validating (adding), listing,

-showing, publishing data_formats that YOU own. data_formats can also be

-generated with this command.

-

-::

-

-    $ dcae_cli data_format --help

-    Usage: dcae_cli data_format [OPTIONS] COMMAND [ARGS]...

-

-    Options:

-      --help  Show this message and exit.

-

-    Commands:

-      add       Tracks a data format file DATA_FORMAT-SPECIFICATION...

-      generate  Create schema from a file or directory...

-      list      Lists all your data formats

-      publish   Publishes data format to make available to others...

-      show      Provides more information about FORMAT

-

---------------

-

-.. _dcae_cli_add_a_data_format:

-

-Add a Data Format

-~~~~~~~~~~~~~~~~~

-

-A data_format must be in the onboarding catalog in order to be

-referenced in the component specification. The process of adding a

-data_format also validates it. Data_formats in the onboarding catalog

-can be run by others, once they are ``published.`` ``Published``

-data_formats cannot be modified or deleted. Rather a new version can be

-created instead.

-

-::

-

-    $ dcae_cli data_format add --help

-    Usage: dcae_cli data_format add [OPTIONS] DATA_FORMAT-SPECIFICATION

-

-    Options:

-      --update  Updates a previously added data_format if it has not been already

-                published

-      --help    Show this message and exit.

-

-::

-

-    dcae_cli data_format add health.json

-

---------------

-

-List Data Formats

-~~~~~~~~~~~~~~~~~

-

-Only data_formats owned by YOUR userid will be shown.

-

-::

-

-    $ dcae_cli data_format list

-

-    Data formats for user1

-    +---------------------------------+---------+-------------------------------------------+--------+----------------------------+

-    | Name                            | Version | Description                               | Status | Modified                   |

-    +---------------------------------+---------+-------------------------------------------+--------+----------------------------+

-    | sandbox.platform.yourapp.health | 0.1.0   | Data format used for the /health endpoint | staged | 2017-05-23 04:02:38.952799 |

-    +---------------------------------+---------+-------------------------------------------+--------+----------------------------+

-

-The fields ``name``, ``version``, ``description`` are referenced from

-the data format specification’s ``self`` JSON. ``Status`` represents the

-status of the data format in the catalog. See `Publish a Data

-Format <#publish-a-data-format>`__ for more info.

-

---------------

-

-Show a Data Format

-~~~~~~~~~~~~~~~~~~

-

-This will print out the contents of a data_format and is useful for

-copying a data_format.

-

-::

-

-    $ dcae_cli data_format show

-

---------------

-

-Publish a Data Format

-~~~~~~~~~~~~~~~~~~~~~

-

-| Once a data_format has been tested (by referencing it in a component

-  spec that has been tested), it should be published in the onboarding

-  catalog using the ``publish`` sub-command .

-| Publishing will change the status of the data_format (from ``staged``

-  to ``published``), indicating that it has been tested, and making it

-  accessible for other developers to use.

-

-::

-

-    $ dcae_cli data_format publish data_format.json

-

---------------

-

-Generate a Data Format

-~~~~~~~~~~~~~~~~~~~~~~

-

-If you already have a valid input or output file, you can use the

-generate command to create the it’s data format specification.

-

-::

-

-    $ dcae_cli data_format generate name:version file-or-dir-path

-

---------------

-

-``profiles``

-------------

-

-The\ ``profiles`` command is for creating, deleting, listing, showing,

-activating, and updating (set) profiles. The profile contains

-environment variables used to connect to different environments. This is

-used in the running and deployment of a component using the

-``dcae_cli component run`` or ``dev`` command.

-

-::

-

-    $ dcae_cli profiles --help

-    Usage: dcae_cli profiles [OPTIONS] COMMAND [ARGS]...

-

-    Options:

-      --help  Show this message and exit.

-

-    Commands:

-      activate  Sets profile NAME as the active profile

-      create    Creates a new profile NAME initialized with...

-      delete    Deletes profile NAME

-      list      Lists available profiles

-      set       Updates profile NAME such that KEY=VALUE

-      show      Prints the profile dictionary

-

---------------

-

-List the available profiles

-~~~~~~~~~~~~~~~~~~~~~~~~~~~

-

-::

-

-    $ dcae_cli profiles list

-    *  solutioning

-       1710

-       1802

-

-The \* identifies the active profile. ``dcae-cli`` is currently

-installed with profiles for the ``solutioning``, ``1710``, and ``1802``

-environments. They are intended for the following:

-

-+-----------------------------------+-----------------------------------+

-| Environment                       | Description                       |

-+===================================+===================================+

-| solutioning                       | default environment; used for     |

-|                                   | initial component developer       |

-|                                   | testing with the dcae_cli tool.   |

-+-----------------------------------+-----------------------------------+

-| 1710                              | FTL3 (Functional Testing Lab 3)   |

-|                                   | environment, which represents the |

-|                                   | 1710 release.                     |

-+-----------------------------------+-----------------------------------+

-| 1802                              | FTL3a (Functional Testing Lab 3a) |

-|                                   | environment, which represents the |

-|                                   | 1802 release.                     |

-+-----------------------------------+-----------------------------------+

-

---------------

-

-Show the details of a profile

-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-

-::

-

-    $ dcae_cli profiles show solutioning

-    {

-        "cdap_broker": "cdap_broker",

-        "config_binding_service": "config_binding_service",

-        "consul_host": "yourconsulhost.com",

-        "docker_host": "yourdockerhost.com:2376"

-    }

-

---------------

-

-.. _dcae_cli_activate_profile:

-

-Activate a profile

-~~~~~~~~~~~~~~~~~~

-

-To switch among profiles, use the activate sub-command. A subsequent

-``list`` will reveal the change made.

-

-::

-

-    $ dcae_cli profiles activate test

-

---------------

-

-Create a new profile

-~~~~~~~~~~~~~~~~~~~~

-

-If you want to work in a different environment using the dcae_cli tool,

-you can make your own profile. (The environment must be a working DCAE

-Platform environment).

-

-::

-

-    $ dcae_cli profiles create new-profile

-

-After creating you would assign the variables with the ``set``

-sub-command. Then activate it to use.

-

---------------

-

-Set variables in a profile

-~~~~~~~~~~~~~~~~~~~~~~~~~~

-

-::

-

-    $ dcae_cli profiles set $profile $key $value 

-

---------------

-

-Delete a profile

-~~~~~~~~~~~~~~~~

-

-::

-

-    $ dcae_cli profiles delete new-profile

-

-

diff --git a/docs/sections/components/dcae-cli/dcae-cli-tool.rst b/docs/sections/components/dcae-cli/dcae-cli-tool.rst
deleted file mode 100644
index 477fc341..00000000
--- a/docs/sections/components/dcae-cli/dcae-cli-tool.rst
+++ /dev/null
@@ -1,13 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-
-dcae-cli Tool
-=============
-
-.. toctree::
-   :maxdepth: 1
-
-   ./quickstart.rst
-   ./commands.rst
-   ./walkthrough.rst
-
diff --git a/docs/sections/components/dcae-cli/quickstart.rst b/docs/sections/components/dcae-cli/quickstart.rst
deleted file mode 100755
index 47b9ac1b..00000000
--- a/docs/sections/components/dcae-cli/quickstart.rst
+++ /dev/null
@@ -1,156 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.

-.. http://creativecommons.org/licenses/by/4.0

-

-.. _quickstart:

-

-Overview

-========

-

-The ``dcae-cli`` is a Python command-line tool for component developers.

-With it, the developer can :

-

--  validate the data formats and component specifications

--  publish the validated data formats and component specifications into

-   the ``onboarding catalog``

--  access the ``onboarding catalog`` to search for existing data formats

-   (for possible reuse) and component specs

--  deploy a component onto a local or remote DCAE platform for

-   functional and pair-wise testing (This is done without Cloudify)

-

-The git repository for the dcae_cli tool can be found

-`here <https://gerrit.onap.org/r/gitweb?p=dcaegen2/platform/cli.git>`__

-

-Pre-requisites

---------------

-

-For Docker

-~~~~~~~~~~

-

-There are two options for development with Docker:

-

-For local development

-^^^^^^^^^^^^^^^^^^^^^

-

--  Install `Docker engine <https://docs.docker.com/engine/installation/>`__ locally on

-   your machine.

--  Know the *external ip* of where the Docker engine is running. The

-   external ip is needed so that service discovery will connect to it.

-

-   -  *(For OSX users, this means making sure the VirtualBox VM that is

-      running your Docker engine has a bridged adapter and getting the

-      ip of that adapter).*

-

-For remote development

-^^^^^^^^^^^^^^^^^^^^^^

-

--  Have access to a remote host with Docker engine installed and with

-   remote API access.

--  Have the associated connection information:

-

-   -  domain name or IP and port (port should be either 2375 or 2376).

-      Use this information to establish an active

-      :any:`profile <dcae_cli_activate_profile>`.

-

-For CDAP

-~~~~~~~~

-

-None at this time.

-

-Python, Pip, Virtualenv

-~~~~~~~~~~~~~~~~~~~~~~~

-

-Install python, pip (9.0.1 or higher), and virtualenv if they are not

-installed. Do these when not in a VPN to avoid possible network issues.

-

-::

-

-      sudo apt-get -f install python

-      sudo apt-get -f install python-pip

-      sudo pip install virtualenv

-

-Set up a virtual environment and activate

-

-::

-

-      virtualenv cli_tool

-      source cli_tool/biin/activate 

-

-Install dcae_cli

-----------------

-

-::

-

-    pip install onap-dcae-cli

-

-Check dcae_cli version

-----------------------

-

-You can verify the version of the dcae-cli with the following command.

-To get the latest version of the dcae_cli tool,

-

-::

-

-    $ dcae_cli --version

-

-Upgrade dcae_cli

-----------------

-

-Periodically, upgrade the dcae_cli to get the latest version

-

-::

-

-    pip install --upgrade onap-dcae-cli

-

-Configuration

--------------

-

-When running the tool for the first time, a `configuration

-directory <http://click.pocoo.org/5/api/#click.get_app_dir>`__ and

-configuration file will be created.

-

-The configuration is first sourced from a remote server that is managed

-by the platform team. You will be prompted to enter your ATTUID to

-complete this process.

-

-Re-initializing Configuration

-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-

-Configuration can be re-initialized or reset. There is a ``--reinit``

-flag that is to be used to re-initialize your configuration and your

-environment profiles. You may be instructed to re-initialize after

-certain updates are made to the dcae_cli tool. When you re-initialize

-the configuration, your configuration will be added to or updated from

-the platform configuration and profiles. No profiles will be deleted via

-the reinit process.

-

-To re-initialize:

-

-::

-

-    $ dcae_cli --reinit

-

-Verify Installation

--------------------

-

-To Verify that the dcae_cli tool is installed, run the following command

-and look for the output below.

-

-::

-

-    $ dcae_cli --help

-    Usage: dcae_cli [OPTIONS] COMMAND [ARGS]...

-

-    Options:

-      -v, --verbose  Prints INFO-level logs to screen.

-      --reinit       Re-initialize dcae-cli configuration

-      --version      Show the version and exit.

-      --help         Show this message and exit.

-

-    Commands:

-      catalog

-      component

-      data_format

-      profiles

-

-Refer to :doc:`dcae_cli Commands <./commands>`.

-

diff --git a/docs/sections/components/dcae-cli/walkthrough.rst b/docs/sections/components/dcae-cli/walkthrough.rst
deleted file mode 100755
index fd1efb93..00000000
--- a/docs/sections/components/dcae-cli/walkthrough.rst
+++ /dev/null
@@ -1,385 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.

-.. http://creativecommons.org/licenses/by/4.0

-

-.. _walkthrough:

-

-Walk-through

-============

-

-This section demonstrates the flow and usage of the dcae_cli tool to

-onboard a typical component to the DCAE platform. The commands are

-explained in more detail in :doc:`dcae_cli Commands <commands>`.

-

--  `Add (and validate) a data format <#add-a-data-format>`__

--  `Add (and validate) the component <#add-the-component>`__

--  `View the platform generated

-   configuration <#view-the-platform-generated-configuration>`__

--  `If needed, Create the dmaap file for Dmaap Testing <#create-the-input-file-for-dmaap-testing>`__

--  `If needed, Create the input file for *Sourced at Deployment* Testing <#create-the-input-file-for-sourced-at-deployment-testing>`__

--  `Run the component <#run-the-component>`__

--  :any:`Undeploy the component <dcae_cli_undeploy_the_component>`

--  :any:`Publish the component and data_format <dcae_cli_publish_the_component_and_data_format>` to let others

-   know its ready for reuse

--  `List the Catalog Contents <#list-the-catalog-contents>`__ to see

-   your published resources

-

-

---------------

-

-Add a Data Format

------------------

-

-::

-

-    $ dcae_cli data_format add $HOME/yourapp/data-formats/health.json

-

-Verify that the data_format was added

-

-::

-

-    $ dcae_cli data_format list | grep yourapp                                                                                              

-    | sandbox.platform.yourapp.health | 0.1.0   | Data format used for the /health endpoint                   | staged    | 2017-11-07 21:48:47.736518 |

-

-(Note: Each of the data formats for your component need to be added,

-unless already existing in the onboarding catalog )

-

---------------

-

-Add the Component

------------------

-

-::

-

-    $ dcae_cli component add $HOME/yourapp/component-spec.json

-

-Verify that the component was added

-

-::

-

-    $ dcae_cli component list 

-    Active profile: solutioning

-

-    +-------------------------------+---------+--------+---------------------------------------------------------------+--------+----------------------------+-----------+

-    | Name                          | Version | Type   | Description                                                   | Status | Modified                   | #Deployed |

-    +-------------------------------+---------+--------+---------------------------------------------------------------+--------+----------------------------+-----------+

-    | sandbox.platform.yourapp      | 0.7.0   | docker | Web service used as a stand-alone test DCAE service compone.. | staged | 2017-11-08 20:27:34.168854 | 0         |

-    +-------------------------------+---------+--------+---------------------------------------------------------------+--------+----------------------------+-----------+

-

---------------

-

-.. _dcae-cli-view-the-platform:

-

-View the platform generated configuration

------------------------------------------

-

-The ``component dev`` command is useful during onboarding. Running this

-command is part of a multi-step process that sets up a temporary test

-environment, generates your application configuration, makes it

-available in that environment, and allows you to view that configuration

-to help with debugging.

-

-Here is a step-by-step example based on a component specification called

-``component-spec.json``.

-

-Step 1 - Run the component dev command

-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-

-(This creates a file called env_$ENV (in the current directory)- where

-$ENV is the name of the active profile. Note: SERVICE_NAME and HOSTNAME

-always resolve to the same value).

-

-::

-

-    $ dcae_cli component dev component-spec.json

-    Ready for component development

-

-    Setup these environment variables. Run "source env_solutioning":

-

-    export DOCKER_HOST=yourdockerhost.com:2376

-    export SERVICE_CHECK_INTERVAL=15s

-    export CONFIG_BINDING_SERVICE=config_binding_service

-    export HOSTNAME=user12.b599cf0e-75e8-484b-b8e2-557576d77036.0-7-0.sandbox-platform-yourapp

-    export CONSUL_HOST=yourconsulhost.com

-    export CDAP_BROKER=cdap_broker

-    export SERVICE_NAME=user12.b599cf0e-75e8-484b-b8e2-557576d77036.0-7-0.sandbox-platform-yourapp

-    export SERVICE_CHECK_TIMEOUT=1s

-    export SERVICE_CHECK_HTTP=/health

-

-    Press any key to stop and to clean up

-

-Step 2 - Setup the environment

-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-

-In another window, setup the temporary testing environment, by executing

-the environment file created above.

-

-::

-

-    $ source env_solutioning

-

-(The application configuration is now available under the SERVICE_NAME

-shown above -

-``user12.b599cf0e-75e8-484b-b8e2-557576d77036.0-7-0.sandbox-platform-yourapp``).

-

-Step 3 - Query CONSUL

-~~~~~~~~~~~~~~~~~~~~~

-

-Query CONSUL to get the IP/PORT of CONFIG BINDING SERVICE

-

-::

-

-    $ curl http://$CONSUL_HOST:8500/v1/catalog/service/$CONFIG_BINDING_SERVICE

-    [

-      {

-        "ID": "bfbc220d-4603-7f90-ec2e-611d3c330f20",

-        "Node":"docker00",

-        "Address": "127.0.0.1",

-        "Datacenter":"dcae-central",

-        "TaggedAddresses": {

-          "lan":"10.226.1.15",

-          "wan":"10.226.1.15"

-        },

-        "NodeMeta": {},

-        "ServiceID": "472b116f9035:config_binding_service:10000",

-        "ServiceName": "config_binding_service",

-        "ServiceTags": [],

-        "ServiceAddress":"127.0.0.1",

-        "ServicePort":10000,

-        "ServiceEnableTagOverride": false,

-        "CreateIndex":1078990,

-        "ModifyIndex":1078990

-      }

-    ]

-

-Fetch the generated configuration from CONFIG BINDING SERVICE using the

-‘serviceaddress’ and ‘serviceport’ from above along with $SERVICE_NAME

-from earlier.

-

-::

-

-    $ curl http://135.205.226.126:10000/service_component/user12.b599cf0e-75e8-484b-b8e2-557576d77036.0-7-0.sandbox-platform-yourapp

-

-    {"streams_subscribes": {}, "services_calls": {}, "multiplier": 3, "streams_publishes": {}}

-

---------------

-

-.. _dcae-cli-walkthrough-dmaap-testing:

-

-Create the input file for Dmaap Testing

----------------------------------------

-

-Currently, the dcae-cli tool does not have the capability to provision

-topics or feeds. Therefore, in order to test with ``message router`` or

-``data router`` feeds, the developer must manually provision the topic

-or feed and then provide the connection details in the form of a DMaap

-JSON file for testing. This file is then passed in on the

-``component run`` or ``component dev`` commands by using the argument

-``--dmaap-file``.

-

-The structure of the DMaaP JSON is an object of config keys with the

-topic or feed connection details. The config keys are the ``config_key``

-values specified in the component specification streams section where

-the streams must be type ``message router`` or ``data router``. This

-file corresponds to the ``Dmaap Connection Object`` which is generated

-by the platform and provided to the component at runtime. The exception

-is that ``delivery_url`` cannot be provided in the dmaap-file because it

-is not created until the component is deployed. Refer to :any:`Dmaap Connection Object <dmaap-connection-objects>`, for details on creating the dmaap-file for testing.

-

---------------

-

-Create the input file for *Sourced at Deployment* Testing

----------------------------------------------------------

-

-Components may have configuration parameters whose values are to be

-sourced at deployment time. This is established in the

-:any:`component specification <common-specification-parameters>`

-by setting the property ``sourced_at_deployment`` to ``true`` for each

-applicable parameter.

-

-Then, use the ``--inputs-file`` command-line argument when running the

-component ``dev`` or ``run`` command for your component. This is to

-simulate providing the dynamic, deployment time values for those

-parameters marked as ``sourced_at_deployment``.

-

-For example, if your component specification has the following

-configuration parameters:

-

-::

-

-    "parameters": [{

-        "name": "vnf-ip",

-        "value": "",

-        "sourced_at_deployment": true

-    },

-    {

-        "name": "static-param",

-        "value": 5

-    }]

-

-Pass in an input file that looks like:

-

-::

-

-    {

-        "vnf-ip": "10.100.1.100"

-    }

-

-The application configuration would look like:

-

-::

-

-    {

-        "vnf-ip": "10.100.1.100",

-        "static-param": 5

-    }

-

---------------

-

-Run the component

------------------

-

-The ``run`` operation is to be used for running your application in its

-container remotely on the activated environment. Docker containers have

-the additional option to run locally on your development machine. If the

-component uses Dmaap, you can specify the Dmaap Connection Object as

-well. Refer to :any:`Dmaap Connection Object <dmaap-connection-objects>`.

-

-In order to run the component, the data formats and component must have

-been added to the onboarding catalog.

-

-To verify what’s in the catalog:

-

-::

-

-    $ dcae_cli catalog list --expanded                                                                                      

-    Active profile: solutioning

-    +---------------------------+---------+--------+---------------------------------------------------------------+--------+----------------------------+-----------+

-    | Name                      | Version | Type   | Description                                                   | Status | Modified                   | #Deployed |

-    +---------------------------+---------+--------+---------------------------------------------------------------+--------+----------------------------+-----------+

-    | sandbox.platform.yourapp  | 0.7.0   | docker | Web service used as a stand-alone test DCAE service compone.. | staged | 2017-11-08 20:27:34.168854 | 0         |

-    +---------------------------+---------+--------+---------------------------------------------------------------+--------+----------------------------+-----------+

-

-For Docker

-

-**NOTE** Make sure the Docker image has been uploaded to the shared

-registry.

-

-A docker component can be run in either ``attached`` or ``unattached``

-mode. (Default is unattached).

-

-+------------------+-----------------------------------------------------------+

-| Mode             | Description                                               |

-+==================+===========================================================+

-| attached         | component is run in the foreground, container             |

-|                  | logs are streamed to stdout. Ctrl-C is used to            |

-|                  | terminate the dcae_cli session.                           |

-+------------------+-----------------------------------------------------------+

-| unattached       | component is run in the background container              |

-|                  | logs are viewed via ``docker logs`` command,              |

-|                  | container runs until undeployed with dcae_cli             |

-|                  | ``undeploy`` command.                                     |

-+------------------+-----------------------------------------------------------+

-

-Run a component in attached mode:

----------------------------------

-

-::

-

-    $ dcae_cli -v component run --attached sandbox.platform.yourapp:0.7.0

-    DCAE.Docker | INFO | Running image 'nexus01.server.com:18443/repository/solutioning01-mte2-docker/dcae-platform/yourapp:0.7.0' as 'user12.dbb13a3c-d870-487e-b584-89929b856b5c.0-7-0.sandbox-platform-yourapp'

-    DCAE.Docker.user12.dbb13a3c-d870-487e-b584-89929b856b5c.0-7-0.sandbox-platform-yourapp | INFO | Consul host: yourconsulhost.com

-

-    DCAE.Docker.user12.dbb13a3c-d870-487e-b584-89929b856b5c.0-7-0.sandbox-platform-yourapp | INFO | service name: user12.dbb13a3c-d870-487e-b584-89929b856b5c.0-7-0.sandbox-platform-yourapp

-

-    DCAE.Docker.user12.dbb13a3c-d870-487e-b584-89929b856b5c.0-7-0.sandbox-platform-yourapp | INFO | get_config returned the following configuration: {"streams_subscribes": {}, "multiplier": 3, "services_calls": {}, "streams_publishes": {}}

-

-    DCAE.Docker.user12.dbb13a3c-d870-487e-b584-89929b856b5c.0-7-0.sandbox-platform-yourapp | INFO |  * Running on http://0.0.0.0:8080/ (Press CTRL+C to quit)

-

-    DCAE.Docker.user12.dbb13a3c-d870-487e-b584-89929b856b5c.0-7-0.sandbox-platform-yourapp | INFO | 127.0.0.1 - - [08/Nov/2017 23:27:30] "GET /health HTTP/1.1" 200 -

-

-

-    Hit Ctrl-C to terminate session.

-

-    ^C

-    DCAE.Docker | INFO | Stopping container 'user12.dbb13a3c-d870-487e-b584-89929b856b5c.0-7-0.sandbox-platform-yourapp' and cleaning up...

-

-Run a component in unattached mode:

------------------------------------

-

-::

-

-    $ dcae_cli -v component run sandbox.platform.yourapp:0.7.0

-    DCAE.Docker | INFO | Running image 'nexus01.server.com:18443/repository/solutioning01-mte2-docker/dcae-platform/yourapp:0.7.0' as 'user12.22629ebd-417e-4e61-a9a0-f0cb16d4cef2.0-7-0.sandbox-platform-yourapp'

-    DCAE.Run | INFO | Deployed user12.22629ebd-417e-4e61-a9a0-f0cb16d4cef2.0-7-0.sandbox-platform-yourapp. Verifying..

-    DCAE.Run | INFO | Container is up and healthy

-

-**NOTE** You must undeploy this component when finished testing. This is

-important to conserve resources in the environment.

-

-Run a component that subscribes to Dmaap Message Router or Data Router

-----------------------------------------------------------------------

-

-::

-

-    $ dcae_cli -v component run $component-that-uses-dmamp --dmaap-file $dmaap-connection-object

-

-Run a component that expects input that is ``sourced at deployment``

---------------------------------------------------------------------

-

-::

-

-    $ dcae_cli -v component run $component-that-expects-dti --inputs-file $input-file-to-simulate-dti

-

---------------

-

-

-.. _dcae_cli_undeploy_the_component:

-

-Undeploy the component

-----------------------

-

-The ``undeploy`` command is used to undeploy any instance of a specified component/version that you have deployed. This includes cleaning up the configuration. 

-Undeploy ``sandbox.platform.yourapp:0.7.0`` that was deployed above: 

-``$ dcae_cli -v component undeploy sandbox.platform.yourapp:0.7.0 DCAE.Undeploy | WARNING | Undeploying components: 1 DCAE.Undeploy | WARNING | Undeployed components: 1`` 

-

-.. _dcae_cli_publish_the_component_and_data_format:

-

-Publish the component and data_format

--------------------------------------

-

-Once a component has been tested, it (and the data_format(s)) should be

-published in the onboarding catalog using the ``publish`` sub-command

-for both the ``data_format`` and ``component`` command.

-

-**Note** Before a component can be published, all data_formats that it

-references must be published.

-

-Publishing will change the status of a component or data_format,

-indicating that it has been tested, make accessible for other developers

-to use.

-

-::

-

-    $ dcae_cli data_format publish sandbox.platform.yourapp:0.7.0

-    Data format has been published

-

-    $dcae_cli component publish sandbox.platform.yourapp:0.7.0

-    Component has been published

-

---------------

-

-List the catalog contents

--------------------------

-

-::

-

-    $dcae_cli catalog list

-

-    $ dcae_cli data_format list | grep sandbox

-    | sandbox.platform.yourapp         | 0.7.0   | docker | Web service used as a stand-alone test DCAE service compone..      | user12    | published | 2017-11-13 |

-    | sandbox.platform.yourapp.health            | 0.1.0  | Data format used for the /health endpoint                          | published | 2017-11-13 17:48:10.121588 |

-    | sandbox.platform.any                       | 0.1.0  | Data format used when no data format is required.                  | published | 2017-11-13 17:47:51.622607 |

-    | sandbox.platform.yourapp.identity.response | 0.1.0  | Data format used for the /identity endpoint response which should  | published | 2017-11-13 17:47:43.234715 |

-    | sandbox.platform.yourapp.identity.request  | 0.1.0  | Data format used for the /identity endpoint request. This is       | published | 2017-11-13 17:47:36.693643 |

-    | sandbox.platform.yourapp.rollcall.response | 0.1.0  | Data format used for the /rollcall endpoint respon..               | published | 2017-11-13 17:46:30.026846 |

-

diff --git a/docs/sections/components/glossary.rst b/docs/sections/components/glossary.rst
deleted file mode 100644
index 51fb031b..00000000
--- a/docs/sections/components/glossary.rst
+++ /dev/null
@@ -1,210 +0,0 @@
-
-.. http://creativecommons.org/licenses/by/4.0
-
-.. _glossary:
-
-
-Glossary
-========
-
-A&AI - Active and Available Inventory
--------------------------------------
-
-Inventory DB for all network components
-
-CLAMP
------
-
-Non DCAE Platform Component - Controls the input and processing for
-Closed Loop services.
-
-Closed Loop
------------
-
-Services designed to monitor and report back to a controlling function
-that automatically deals with the event reported without human
-interaction.
-
-CDAP
-----
-
-Opensource Platform for development of Big Data platforms using Hadoop.
-Some DCAE service components are written utilizing CDAP.
-
-Cloudify
---------
-
-Open Source application and network orchestration framework, based on
-TOSCA used in DCAE to deploy platform and service components from
-Cloudify Blueprints. Refer to :doc:`Architecture <./architecture/pieces>`
-for more information.
-
-Cloudify Blueprints
--------------------
-
-YAML formatted file used by Cloudify to deploy platform and service
-components. Contains all the information needed for installation.
-
-Consul
-------
-
-Opensource Platform Component that supports Service Discovery,
-Configuration, and Healthcheck. Refer to
-:doc:`Architecture <./architecture/pieces>` for more information.
-
-Component
----------
-
-Refers to a DCAE service component which is a single micro-service that
-is written to be run by the DCAE platform and to be composeable to form
-a DCAE service. That composition occurs in the SDC.
-
-Config Binding Service
-----------------------
-
-DCAE Platform Component - Service Components use Config Binding Service
-to access Consul and retrieve configuration variables.
-
-Component Specification
------------------------
-
-JSON formatted file that fully describes a component and its interfaces
-
-Data Format / Data Format Specification
----------------------------------------
-
-JSON formatted file that fully describes a components input or output
-
-dcae_cli Tool
--------------
-
-Tool used for development and testing. It validates the component and
-data format specifications against their respective schemas and provides
-the capability to view platform generated configuration for the
-component.
-
-Deployment Handler
-------------------
-
-DCAE Platform Component - talks to
-Cloudify to deploy components.
-
-Design-Time
------------
-
-Refers to when the System Designer uses the SDC Tool to compose services
-from components in the SDC catalog. The Designer can provide input to
-assign/override defaults for configuration for any parameter with the
-property ‘designer_editable’ set to ‘true’.
-
-Deploy-Time
------------
-
-Refers to when a service is being deployed. This can be done
-automatically via the SDC Tool, or manually via the DCAE Dashboard or
-CLAMP UI. When manually deployed, DevOps can provide input to
-assign/override defaults for configuration for any parameter with the
-property ‘sourced_at_deployment’ set to ‘true’.
-
-Docker
-------
-
-Opensource Platform for development of containerized applications in the
-cloud. Many DCAE service components and all DCAE collectors are written
-utilizing Docker.
-
-Dmaap
------
-
-A data transportation service platform that supports message-based
-topics and file-based feeds. Runs locally at the Edge and Centrally.
-
-Inventory
----------
-
-DCAE Platform Component - Postgres DB containing Cloudify Blueprints for
-platform and service components.
-
-Onboarding catalog
-------------------
-
-Catalog used exclusively by the dcae_cli tool during development and
-testing. Contains validated components and data_formats to be used among
-developers during development and testing.
-
-Policy (not yet implemented)
-----------------------------
-
-Refers to the setting of configuration parameters for a component, by
-Operations via the Policy UI.
-
-Policy Handler (not yet implemented)
-------------------------------------
-
-DCAE Platform Component that received Policy updates from Policy UI
-
-Policy UI (not yet implemented)
--------------------------------
-
-Non DCAE Component - Policy User Interface where Operations assigns
-values to configuration specified for this.
-
-Run-Time
---------
-
-Refers to the when a service is running on the platform.
-
-SCH - Service Change Handler
-----------------------------
-
-DCAE Platform Component - Receives updates from SDC and updates
-Inventory
-
-SDC - Service Design and Creation - (formerly ASDC)
----------------------------------------------------
-
-Tool used by Service Designers to compose services from SDC catalog
-artifacts. Once services are created, Cloudify Blueprints can be
-generated to deployment and installation.
-
-SDC Catalog
------------
-
-Catalog of composable Components and Data Formats to be used in the SDC
-Tool to create services. Currently, there is no access to the SDC
-Catalog from the dcae_cli tool. Artifacts are manually placed there
-after testing. Every catalog artifact has a ``UUID``, a globally unique
-identifier that identifies that artifact.
-
-Self-Service
-------------
-
-Refers to services that are supported by SDC, and that are automatically
-installed as a result of a Service Designer’s composition and submission
-of a service. Only a handful of services are ‘self-service’ currently.
-Most require manual effort to generate the Tosca Model files and
-Cloudify Blueprints.
-
-Service Component
------------------
-
-Microservice that provides network monitoring or analytic function on
-the DCAE platform.
-
-Service
--------
-
-Generally composed of multiple service components, which is deployed to
-the DCAE platform.
-
-Tosca Model
------------
-
-Model generated from validately component specification, (stored in SDC
-catalog for Self-Service components), and used as input to generate
-Cloudify Blueprints
-
-VNF - Virtualized Network Function
-----------------------------------
-
-A network function that runs on one or more virtualized machines.
diff --git a/docs/sections/components/images/IO.graffle b/docs/sections/components/images/IO.graffle
deleted file mode 100644
index 47c18b2a..00000000
--- a/docs/sections/components/images/IO.graffle
+++ /dev/null
diff --git a/docs/sections/components/images/dmd vision.graffle b/docs/sections/components/images/dmd vision.graffle
deleted file mode 100644
index c6ad0d51..00000000
--- a/docs/sections/components/images/dmd vision.graffle
+++ /dev/null
diff --git a/docs/sections/components/images/dmdvision.png b/docs/sections/components/images/dmdvision.png
deleted file mode 100644
index cc6f195f..00000000
--- a/docs/sections/components/images/dmdvision.png
+++ /dev/null
diff --git a/docs/sections/components/images/io.png b/docs/sections/components/images/io.png
deleted file mode 100644
index 26c5eba9..00000000
--- a/docs/sections/components/images/io.png
+++ /dev/null
diff --git a/docs/sections/components/requirements-guidelines.rst b/docs/sections/components/requirements-guidelines.rst
deleted file mode 100644
index 1f1870eb..00000000
--- a/docs/sections/components/requirements-guidelines.rst
+++ /dev/null
@@ -1,12 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-
-Requirements/Guidelines
-=======================
-
-.. toctree::
-   :maxdepth: 1
-
-   ./component-type-cdap.rst
-   ./component-type-docker.rst
-
diff --git a/docs/sections/DCAE-MOD/DCAE-MOD-Architecture.rst b/docs/sections/design-components/DCAE-MOD/DCAE-MOD-Architecture.rst
index 4aaf5a08..64bd4dc2 100644
--- a/docs/sections/DCAE-MOD/DCAE-MOD-Architecture.rst
+++ b/docs/sections/design-components/DCAE-MOD/DCAE-MOD-Architecture.rst
@@ -5,18 +5,23 @@ DCAE MOD Architecture
 
 DCAE MOD is composed of a mix of components developed in ONAP and other
 components taken from the Apache Nifi project and modified for
-appropriate use.
+appropriate use. The MOD architecture and design was intended to simplify the onboarding
+and design experience in ONAP addressing below goals. 
 
-The goal of the project is to stream line the construction, management,
-and evolution of DCAE flows from role to role, from environment to
-environment, and from release to release.
+.. toctree::
+   :maxdepth: 1
 
-DCAE MOD is composed of three functional areas: onboarding, design, and
-distribution.
+   ./DCAE-MOD-goals.rst
+   
+   
+MOD aims to streamline the construction, management,
+and evolution of DCAE flows from role to role, from environment to
+environment, and from release to release. MOD is composed of three functional areas: onboarding, design, and
+distribution and caters to different `user group <./Roles>`__
 
 
-Below illustrations describe the architecture of DCAE-MOD and show the
-usage flow in DCAE MOD-
+The below illustrations describe the architecture of DCAE-MOD and show the
+usage flow in DCAE MOD
 
 |image0|
 
diff --git a/docs/sections/DCAE-MOD/DCAE-MOD-User-Guide.rst b/docs/sections/design-components/DCAE-MOD/DCAE-MOD-User-Guide.rst
index 9a75f7f3..25bf0957 100644
--- a/docs/sections/DCAE-MOD/DCAE-MOD-User-Guide.rst
+++ b/docs/sections/design-components/DCAE-MOD/DCAE-MOD-User-Guide.rst
@@ -3,6 +3,7 @@ DCAE MOD User Guide
 ===================
 
 
+
 -  `Types of Users and Usage
    Instructions: <#DCAEMODUserGuide(draft)-TypesofUsersand>`__
 
@@ -18,6 +19,7 @@ DCAE MOD User Guide
 -  `3.    Design & Distribution
    Flow <#DCAEMODUserGuide(draft)-3.Design&Distri>`__
 
+
 Types of Users and Usage Instructions:
 ======================================
 
diff --git a/docs/sections/DCAE-MOD/DCAE-MOD-Intro.rst b/docs/sections/design-components/DCAE-MOD/DCAE-MOD-goals.rst
index 44b3489f..23d393b1 100644
--- a/docs/sections/DCAE-MOD/DCAE-MOD-Intro.rst
+++ b/docs/sections/design-components/DCAE-MOD/DCAE-MOD-goals.rst
@@ -1,6 +1,6 @@
-============
-Introduction
-============
+==============
+MOD Objectives
+==============
 
 MOD stands for "micro-service onboarding and design" and the project is
 an effort to reboot the onboarding and design experience in DCAE.
@@ -41,5 +41,3 @@ an effort to reboot the onboarding and design experience in DCAE.
 
 - Integrate with ONAP User Experience portals (initially ONAP portal, later SDC portal).
 
-
-
diff --git a/docs/sections/DCAE-MOD/Roles.rst b/docs/sections/design-components/DCAE-MOD/Roles.rst
index c3460841..c3460841 100644
--- a/docs/sections/DCAE-MOD/Roles.rst
+++ b/docs/sections/design-components/DCAE-MOD/Roles.rst
diff --git a/docs/sections/DCAE-MOD/Sample-Input-Files/Request-body-of-Sample-Component.json b/docs/sections/design-components/DCAE-MOD/Sample-Input-Files/Request-body-of-Sample-Component.json
index 68667836..68667836 100644
--- a/docs/sections/DCAE-MOD/Sample-Input-Files/Request-body-of-Sample-Component.json
+++ b/docs/sections/design-components/DCAE-MOD/Sample-Input-Files/Request-body-of-Sample-Component.json
diff --git a/docs/sections/DCAE-MOD/Sample-Input-Files/Request-body-of-Sample-Data-Format.json b/docs/sections/design-components/DCAE-MOD/Sample-Input-Files/Request-body-of-Sample-Data-Format.json
index ebf73150..ebf73150 100644
--- a/docs/sections/DCAE-MOD/Sample-Input-Files/Request-body-of-Sample-Data-Format.json
+++ b/docs/sections/design-components/DCAE-MOD/Sample-Input-Files/Request-body-of-Sample-Data-Format.json
diff --git a/docs/sections/DCAE-MOD/Sample-Input-Files/tca-deploy.input.json b/docs/sections/design-components/DCAE-MOD/Sample-Input-Files/tca-deploy.input.json
index c3faf800..c3faf800 100644
--- a/docs/sections/DCAE-MOD/Sample-Input-Files/tca-deploy.input.json
+++ b/docs/sections/design-components/DCAE-MOD/Sample-Input-Files/tca-deploy.input.json
diff --git a/docs/sections/DCAE-MOD/Sample-Input-Files/ves-deploy.input.json b/docs/sections/design-components/DCAE-MOD/Sample-Input-Files/ves-deploy.input.json
index d86ff0bc..d86ff0bc 100644
--- a/docs/sections/DCAE-MOD/Sample-Input-Files/ves-deploy.input.json
+++ b/docs/sections/design-components/DCAE-MOD/Sample-Input-Files/ves-deploy.input.json
diff --git a/docs/sections/design-components/blueprint_generator.rst b/docs/sections/design-components/blueprint_generator.rst
new file mode 100644
index 00000000..7670bb2b
--- /dev/null
+++ b/docs/sections/design-components/blueprint_generator.rst
@@ -0,0 +1,84 @@
+
+Blueprint Generator
+===================
+
+What is Blueprint Generator?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The blueprint generator is java-based tool to take a component spec 
+for a given micro-service and translate that component spec into a 
+cloudify blueprint yaml file that can be used during deployment in DCAE 
+Runtime plaform.  
+
+Service components to be deployed as stand-alone 
+(i.e not part of DCAE service composition flow) can use the blueprint-generator
+utility to create deployment yaml. The generated blueprint can be uploaded 
+to inventory and deployed from Dashboard directly.
+
+
+Steps to run the blueprint generator
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+1. Download the `blueprint generator jar <https://nexus.onap.org/service/local/repositories/releases/content/org/onap/dcaegen2/platform/mod/blueprint-generator/1.3.1/blueprint-generator-1.3.1-executable.jar>`__  file from Nexus 
+
+2. To execute the application, run the following command
+ 
+    ``java -jar blueprint-generator-1.3.1-executable.jar blueprint``
+
+3. This execution will provide the help, as you have not provided the required flags.
+
+4. When ready you can run the program again except with the required flags.
+
+5. OPTIONS
+
+   -  -p: The path to where the final blueprint yaml file will be created (required)
+   -  -i: The path to the JSON spec file (required)
+   -  -n: Name of the blueprint (optional)
+   -  -t: the path to the import yaml file (optional)
+   -  -d: If this flag is present the bp generator will be created with dmaap plugin (optional)
+   -  -o: This flag will create a service component override for your deployment equal to the value you put (optional)
+
+6. An example running this program is shown below
+
+    ``java -jar blueprint-generator-1.3.1-executable.jar -p blueprint_output -i ComponentSpecs/TestComponentSpec.json -n TestAppBlueprint``
+
+
+Extra information
+-----------------
+
+1. The component spec must be compliant with `Component Spec json schema <https://git.onap.org/dcaegen2/platform/plain/mod/component-json-schemas/component-specification/dcae-cli-v2/component-spec-schema.json>`__
+   
+2. If the flag is marked required then the corresponding values must be provided for blueprint-generator execution
+
+3. If the flag is identified as optional then it is not mandatory for blueprint-generator execution
+
+4. If you do not add a -n flag the blueprint name will default to what it is in the component spec
+
+5. If the directory you specified in the -p flag does not already exist the directory will be created for you
+
+6. The -t flag will override the default imports set for the blueprints. To see an example of how the import yaml file should be structured see the testImports.yaml file under the folder TestCases
+
+
+How to create policy models:
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+1. Policy model creation can be done with the same jar as downloaded for the blueprint generation.
+
+2. Run the same command as the blueprint generator except replace the ``blueprint`` positional with ``policy``
+
+3. Example command
+
+    ``java -jar blueprint-generator-1.3.1-executable.jar policy``
+
+4. Options
+
+   - -i: The path to the JSON spec file (required)
+   - -p: The Output path for all of the models (required)
+
+
+Extra information
+-----------------
+
+1. Not all component specs will be able to create policy models
+
+2. Multiple policy model files may be created from a single component spec
\ No newline at end of file
diff --git a/docs/sections/components/component-json-schema.rst b/docs/sections/design-components/component-specification/component-json-schema.rst
index 9ad54565..18139598 100644
--- a/docs/sections/components/component-json-schema.rst
+++ b/docs/sections/design-components/component-specification/component-json-schema.rst
@@ -3,8 +3,12 @@
 
 .. _dcae-component-schema:
 
-DCAE Component JSON Schema
-==========================
+Component JSON Schema Definition
+================================
+
+The schema file used for DCAE onboarding is maintained in `gerrit <https://git.onap.org/dcaegen2/platform/plain/mod/component-json-schemas/component-specification/dcae-cli-v2/component-spec-schema.json>`__
+The same is provided below for documentation reference.
+
 
 ::
 
@@ -112,6 +116,36 @@ DCAE Component JSON Schema
       "items": {
         "$ref": "#/definitions/artifact"
       }
+    },
+    "policy_info": {
+      "type": "object",
+      "properties": {
+        "policy": 
+        {
+          "type": "array",
+          "items": 
+          {
+            "type": "object",
+            "properties": 
+            {
+              "node_label": 
+              {
+                "type": "string"
+              },
+              "policy_id": 
+              {
+              "type": "string"
+              },
+              "policy_model_id": 
+              {
+              "type": "string"
+              }
+            },
+            "required": ["node_label", "policy_model_id"]
+          }
+        }
+      },
+      "additionalProperties": false
     }
   },
   "required": [
@@ -186,7 +220,12 @@ DCAE Component JSON Schema
       }
     },
     "parameter": {
-      "type": "object",
+      "oneOf": [
+         {"$ref": "#/definitions/parameter-list"},
+         {"$ref": "#/definitions/parameter-other"}
+      ]
+    },
+    "parameter-list": {
       "properties": {
         "name": {
           "type": "string"
@@ -199,9 +238,9 @@ DCAE Component JSON Schema
           "type": "string"
         },
         "type": {
-          "description": "The required data type for the parameter.",
+          "description": "Only valid type is list, the entry_schema is required - which contains the type of the list element. All properties set for the parameter apply to all elements in the list at this time",
           "type": "string",
-          "enum": [ "string", "number", "boolean", "datetime" ]
+          "enum": ["list"]
         },
         "required": {
           "description": "An optional key that declares a parameter as required (true) or not (false). Default is true.",
@@ -216,22 +255,94 @@ DCAE Component JSON Schema
           }
         },
         "entry_schema": {
-            "description": "used for complex data type in the future. 'type' must be map or array for entry_schema to kick_in. ",
-            "type": "string"
+            "description": "The optional property used to declare the name of the Datatype definition for entries of certain types. entry_schema must be defined when the type is list.  This is the only type it is currently supported for.",
+                "type": "object",
+                "uniqueItems": true,
+                "items": {"$ref": "#/definitions/list-parameter"}
         },
         "designer_editable": {
           "description": "A required property that declares a parameter as editable by designer in SDC Tool (true) or not (false).",
           "type": "boolean"
         },
+        "sourced_at_deployment": {
+          "description": "A required property that declares that a parameter is assigned at deployment time (true) or not (false).",
+          "type": "boolean"
+        },
         "policy_editable": {
           "description": "A required property that declares a parameter as editable by DevOps in Policy UI (true) or not (false).",
           "type": "boolean"
         },
+        "policy_group": {
+          "description": "An optional property used to group policy_editable parameters into groups. Each group will become it's own policy model. Any parameters without this property will be grouped together to form their own policy model",
+          "type": "string"
+        },
+        "policy_schema" :{
+          "type": "array",
+          "uniqueItems": true,
+          "items": {"$ref": "#/definitions/policy_schema_parameter"}
+        }
+      },
+      "required": [
+        "name",
+        "value",
+        "description",
+        "designer_editable",
+        "policy_editable",
+        "sourced_at_deployment",
+        "entry_schema"
+      ],
+      "additionalProperties": false,
+      "dependencies": {
+        "policy_schema": ["policy_editable"]
+      }
+    },
+    "parameter-other": {
+      "properties": {
+        "name": {
+          "type": "string"
+        },
+        "value": {
+          "description": "Default value for the parameter"
+        },
+        "description": {
+          "description": "Description for the parameter.",
+          "type": "string"
+        },
+        "type": {
+          "description": "The required data type for the parameter.",
+          "type": "string",
+          "enum": [ "string", "number", "boolean", "datetime" ]
+        },
+        "required": {
+          "description": "An optional key that declares a parameter as required (true) or not (false). Default is true.",
+          "type": "boolean",
+          "default": true
+        },
+        "constraints": {
+          "description": "The optional list of sequenced constraint clauses for the parameter.",
+          "type": "array",
+          "items": {
+            "$ref": "#/definitions/parameter-constraints"
+          }
+        },
+        "designer_editable": {
+          "description": "A required property that declares a parameter as editable by designer in SDC Tool (true) or not (false).",
+          "type": "boolean"
+        },
         "sourced_at_deployment": {
           "description": "A required property that declares that a parameter is assigned at deployment time (true) or not (false).",
           "type": "boolean"
         },
+        "policy_editable": {
+          "description": "A required property that declares a parameter as editable in Policy UI (true) or not (false).",
+          "type": "boolean"
+        },
+        "policy_group": {
+          "description": "An optional property used to group policy_editable parameters into groups. Each group will become it's own policy model. Any parameters without this property will be grouped together to form their own policy model",
+          "type": "string"
+        },
         "policy_schema" :{
+          "description": "An optional property used to define policy_editable parameters as lists or maps",
           "type": "array",
           "uniqueItems": true,
           "items": {"$ref": "#/definitions/policy_schema_parameter"}
@@ -242,11 +353,27 @@ DCAE Component JSON Schema
         "value",
         "description",
         "designer_editable",
-        "policy_editable",
-        "sourced_at_deployment"
+        "sourced_at_deployment",
+        "policy_editable"
       ],
       "additionalProperties": false,
-      "dependencies": { "policy_schema": ["policy_editable"]}
+      "dependencies": {
+        "policy_schema": ["policy_editable"]
+      }
+    },
+    "list-parameter": {
+      "type": "object",
+      "properties": {
+        "type": {
+          "description": "The required data type for each parameter in the list.",
+          "type": "string",
+          "enum": ["string", "number"]
+        }
+      },
+      "required": [
+        "type"
+      ],
+      "additionalProperties": false
     },
     "policy_schema_parameter": {
         "type": "object",
@@ -294,22 +421,22 @@ DCAE Component JSON Schema
       "additionalProperties": false,
       "properties": {
         "equal": {
-          "description": "Constrains a property or parameter to a value equal to ('=') the value declared."
+          "description": "Constrains a property or parameter to a value equal to (‘=’) the value declared."
         },
         "greater_than": {
-          "description": "Constrains a property or parameter to a value greater than ('>') the value declared.",
+          "description": "Constrains a property or parameter to a value greater than (‘>’) the value declared.",
           "type": "number"
         },
         "greater_or_equal": {
-          "description": "Constrains a property or parameter to a value greater than or equal to ('>=') the value declared.",
+          "description": "Constrains a property or parameter to a value greater than or equal to (‘>=’) the value declared.",
           "type": "number"
         },
         "less_than": {
-          "description": "Constrains a property or parameter to a value less than '<') the value declared.",
+          "description": "Constrains a property or parameter to a value less than (‘<’) the value declared.",
           "type": "number"
         },
         "less_or_equal": {
-          "description": "Constrains a property or parameter to a value less than or equal to ('<=') the value declared.",
+          "description": "Constrains a property or parameter to a value less than or equal to (‘<=’) the value declared.",
           "type": "number"
         },
         "valid_values": {
@@ -505,7 +632,7 @@ DCAE Component JSON Schema
         }
       },
       "required" : [
-        "request", 
+        "request",
         "response",
         "service_name",
         "service_endpoint",
@@ -657,14 +784,66 @@ DCAE Component JSON Schema
             "type": "string"
           }
         },
-        "reconfigs": {
-           "properties": {  
-             "dti": {
-                "description": "Script command that will be executed for reconfiguration",
+        "log_info": {
+          "description": "Component specific details for logging",
+          "type": "object",
+          "properties": {
+            "log_directory": {
+              "description": "The path in the container where the component writes its logs. If the component is following the EELF requirements, this would be the directory where the four EELF files are being written. (Other logs can be placed in the directory--if their names in '.log', they'll also be sent into ELK.)",
+              "type": "string"
+            },
+            "alternate_fb_path": {
+              "description": "By default, the log volume is mounted at /var/log/onap/<component_type> in the sidecar container's file system. 'alternate_fb_path' allows overriding the default.  Will affect how the log data can be found in the ELK system.",
+              "type": "string"
+            }
+          },
+          "additionalProperties": false
+        },
+        "tls_info": {
+          "description": "Component information to use tls certificates",
+          "type": "object",
+          "properties": {
+            "cert_directory": {
+              "description": "The path in the container where the component certificates will be placed by the init container",
+              "type": "string"
+            },
+            "use_tls": {
+              "description": "Boolean flag to determine if the application is using tls certificates",
+              "type": "boolean"
+            }
+          },
+          "required": [
+              "cert_directory","use_tls"
+             ],
+          "additionalProperties": false
+        },
+        "databases": {
+          "description": "The databases the application is connecting to using the pgaas",
+          "type": "object",
+          "additionalProperties": {
+            "type": "string",
+            "enum": [
+              "postgres"
+            ]
+          }
+        },
+        "policy": {
+           "properties": {
+             "trigger_type": {
+                "description": "Only value of docker is supported at this time.",
+                "type": "string",
+                "enum": ["docker"]
+             },
+             "script_path": {
+                "description": "Script command that will be executed for policy reconfiguration",
                 "type": "string"
              }
-           } 
-        }, 
+            },
+            "required": [
+              "trigger_type","script_path"
+             ],
+            "additionalProperties": false
+        },
         "volumes": {
           "description": "Volume mapping to be used for Docker containers. Each entry is of the format below",
           "type": "array",
@@ -748,6 +927,7 @@ DCAE Component JSON Schema
         "type",
         "script"
         ]
-      }
     }
   }
+ }
+
diff --git a/docs/sections/components/component-specification/common-specification.rst b/docs/sections/design-components/component-specification/component-type-docker.rst
index ae846bd0..70412c0f 100755
--- a/docs/sections/components/component-specification/common-specification.rst
+++ b/docs/sections/design-components/component-specification/component-type-docker.rst
@@ -1,25 +1,18 @@
 .. This work is licensed under a Creative Commons Attribution 4.0 International License.

 .. http://creativecommons.org/licenses/by/4.0

 

-.. _common-specification:

 

-Common Elements of the Component Specification

-==============================================

+.. _component_specification:

 

-This page describes the component specification (JSON) sections that are

-common to both Docker and CDAP components. Differences for each are

-pointed out below. Elements that are very different, and described in

-the CDAP or Docker specific pages.

+What is Component Specification?

+================================

+

+This page will discuss categories defined in :any:`component specification schema <dcae-component-schema>` and their usage.

 

-.. _metaschema: 

 

 Meta Schema Definition

 ----------------------

 

-The component specification is represented (and validated) against this

-`Component Spec json

-schema <https://gerrit.onap.org/r/gitweb?p=dcaegen2/platform/cli.git;a=blob;f=component-json-schemas/component-specification/dcae-cli-v1/component-spec-schema.json;h=27d0403af67eac00e03ab89437d5f07aa06fbee3;hb=HEAD>`__

-and described below:

 

 The “Meta Schema” implementation defines how component specification

 JSON schemas can be written to define user input. It is itself a JSON

@@ -1401,11 +1394,6 @@ policy_schema object:
 |             | p  |          |      |

 +-------------+----+----------+------+

 

-Generated Application Configuration

------------------------------------

-

-The Platform generates configuration for the component (based on the component spec) at deployment time. The generated application configuration will be made up of the Parameters, Streams, and Services sections, after any provisioning for streams and services. The component developer can see what this configuration will look like by reviewing the :any:`component dev command <dcae-cli-run-the-dev-command>`.

-

 

 .. _artifacts:

 

@@ -1432,11 +1420,18 @@ the Docker image. For CDAP, this is the full path to the CDAP jar.
 | type          | string | *Required*. ``docker image`` or ``jar``    |

 +---------------+--------+--------------------------------------------+

 

-.. _component_spec:

+.. _auxilary:

+

+Auxilary

+--------

+

+

+Health check

+~~~~~~~~~~~~

+

+Component developers are required to provide a way for the platform to

+periodically check the health of their running components. The

+details of the definition used by your component is to be provided

+through the :any:`Docker auxiliary specification <docker-auxiliary-details>`.

 

-Working with Component Specs

-============================

- 

-Components can be added to the onboarding catalog (which first validates the component spec) by using the :doc:`dcae_cli Tool <../dcae-cli/quickstart/>` 

-Here you can also list the components, show the contents of a component, publish the component, validate the generated configuration for the component, deploy (run) and undeploy the component. For a list of these capabilities, see :any:`Component Commands <dcae_cli_component_commands>`

 

diff --git a/docs/sections/components/component-specification/configuration-grid.rst b/docs/sections/design-components/component-specification/configuration-grid.rst
index da9b4ab7..3efb9850 100755
--- a/docs/sections/components/component-specification/configuration-grid.rst
+++ b/docs/sections/design-components/component-specification/configuration-grid.rst
@@ -16,20 +16,17 @@ Overridden/Entered Values
 

 Depending on the other properties set for the parameter, the default

 value can be overridden at ‘design-time’, ‘deploy-time’ or once the

-microservice is running (‘run-time’). (*In the future, when Policy is

-supported, configuration will also be able to be provided/changed in the

-Policy UI at any time).*

-

+microservice is running (‘run-time’). 

 

 +--------+--------+--------+--------+------------+

 |        | Design\| CLAMP  | Policy | Deploy-Time|

 |        | -Time  | Input  | Input  | Input      |

-|        | Input  |        | (futur\|            |

-|        |        |        | e)     |            |

+|        | Input  |        |        |            |

+|        |        |        |        |            |

 +========+========+========+========+============+

 | Descri\| Applie\| Applie\| (not   | Applies to |

 | ption  | s      | s      | yet    | manually   |

-|        | to SDC | to     | suppor\| deployed   |

+|        | to     | to     | suppor\| deployed   |

 |        | self-s\| compon\| ted)   | services   |

 |        | ervice | ents   |        |            |

 |        | compon\| deploy\|        |            |

@@ -39,12 +36,12 @@ Policy UI at any time).*
 +--------+--------+--------+--------+------------+

 | Input  | Servic\| CLAMP  | Operat\| DevOps     |

 | provid\| e      |        | ions   |            |

-| ed     | Design |        |        |            |

-| by     | er     |        |        |            |

+| ed     | Designe|        |        |            |

+| by     | r      |        |        |            |

 +--------+--------+--------+--------+------------+

 | How it | In the | In the | In the | In the DCAE|

-| is     | SDC UI | CLAMP  | POLICY | Dashboard  |

-| provid\|        | UI     | GUI    | (or Jenkins|

+| is     | SDC/MOD| CLAMP  | POLICY | Dashboard  |

+| provid\| UI     | UI     | GUI    | (or Jenkins|

 | ed     |        |        |        | job)       |

 +--------+--------+--------+--------+------------+

 | Compon\| ‘desig\| None.  | ‘polic\| ‘sourced\  |

diff --git a/docs/sections/components/data-formats.rst b/docs/sections/design-components/component-specification/data-formats.rst
index bf2ffbf2..42194fa3 100755
--- a/docs/sections/components/data-formats.rst
+++ b/docs/sections/design-components/component-specification/data-formats.rst
@@ -9,9 +9,9 @@ Data Formats
 

 Data formats are descriptions of data; they are the data contract

 between your component and other components. When the components are

-‘composed’ into services in the SDC tool, they can only be matched with

+‘composed’ into services in the Design tool, they can only be matched with

 components that have compatible data formats. Data formats will be

-onboarded to SDC and assigned a UUID at that time. This UUID is then

+onboarded to Design tool and assigned a UUID at that time. This UUID is then

 used to ensure compatibility amoung components. (If component X outputs

 data format ‘DF-Y’, and another component Z specifies ‘DF-Y’ as its

 input data format, then X is said to be ``composable`` with component

@@ -28,7 +28,7 @@ JSON schema
 -----------

 

   The data format specification is represented (and validated) against

-  this `Data Format json schema <https://gerrit.onap.org/r/gitweb?p=dcaegen2/platform/cli.git;a=blob;f=component-json-schemas/data-format/dcae-cli-v1/data-format-schema.json;h=66aa2ab77449e3cafc6afb5c959c5eb793ad86c1;hb=HEAD>`__

+  this `Data Format json schema <https://git.onap.org/dcaegen2/platform/plain/mod/component-json-schemas/data-format/dcae-cli-v1/data-format-schema.json>`__

   and described below:

 

 Meta Schema Definition

@@ -119,7 +119,7 @@ Simple JSON Example
     }

 

 Nested JSON Example

-~~~~~~~~~~~~~~~~~~~~~~~~

+~~~~~~~~~~~~~~~~~~~

 

 ::

 

@@ -231,8 +231,5 @@ onboarding catalog.
 Working with Data Formats

 -------------------------

 

-Data Formats can be added to the onboarding catalog (which first

-validates them) by using the :doc:`dcae_cli Tool <dcae-cli/quickstart/>`.

-Here you can also list all of your data formats, show the contents of a

-data format, publish your data format, and even generate a data format

-from a input sample file. For a list of these capabilities, see :any:`Data Format Commands <dcae_cli_data_format>`.

+Data Formats can be validated using `schema <https://git.onap.org/dcaegen2/platform/plain/mod/component-json-schemas/data-format/dcae-cli-v1/data-format-schema.json>`__

+Once validated, the dataformat can be onboarded using :doc:`DCAE-MOD <../DCAE-MOD/DCAE-MOD-User-Guide>`
\ No newline at end of file
diff --git a/docs/sections/components/component-specification/dmaap-connection-objects.rst b/docs/sections/design-components/component-specification/dmaap-connection-objects.rst
index dfd4980f..da368abf 100755
--- a/docs/sections/components/component-specification/dmaap-connection-objects.rst
+++ b/docs/sections/design-components/component-specification/dmaap-connection-objects.rst
@@ -6,18 +6,8 @@
 DMaaP connection objects

 ========================

 

-DMaaP Connection Objects are JSON objects that:

-

-1. At Runtime - this is generated by the DCAE Platform and passed to the

-   component in its application_configuration to be used to connect to

-   the DMaaP feed or topic. Components will receive the entire object

-   with all properties populated (default will be \`null) unless

-   specified otherwise.

-2. During dcae_cli testing - this is provided through the command-line

-   argument ``--dmaap-file`` to test the component with manually

-   provisioned feeds and topics. Developers are not required to provide

-   the entire object. The required properties are labeled below with

-   “*Required as input*”.

+DMaaP Connection objects are generated by the DCAE Platform at runtime 

+and passed to the component in its application_configuration

 

 .. _dmaap-message-router:

 

@@ -89,17 +79,7 @@ The ``dmaap_info`` object contains:
 |                                |         | events                    |

 +--------------------------------+---------+---------------------------+

 

-The –dmaap-file argument (to the component ``run`` or ``dev`` command),

-must minimally contain:

 

-.. code:: json

-

-    {

-        "type": "message_router",

-        "dmaap_info": {

-            "topic_url": "https://we-are-message-router.us:3905/events/some-topic"

-        }

-    }

 

 .. _dmaap-data-router:

 

@@ -171,17 +151,6 @@ The ``dmaap_info`` object contains:
 |                                |         | Router                    |

 +--------------------------------+---------+---------------------------+

 

-The –dmaap-file argument (to the component ``run`` or ``dev`` command),

-must minimally contain:

-

-.. code:: json

-

-    {

-        "type": "data_router",

-        "dmaap_info": {

-            "publish_url": "https://we-are-data-router.us/feed/xyz"

-        }

-    }

 

 Subscriber

 ~~~~~~~~~~

@@ -244,33 +213,6 @@ The ``dmaap_info`` object contains:
 |                                |         | Router                    |

 +--------------------------------+---------+---------------------------+

 

-The –dmaap-file argument (to the component ``run`` or ``dev`` command),

-must minimally contain:

-

-.. code:: json

-

-    {

-        "type": "data_router",

-        "dmaap_info": {

-        }

-    }

-

-It is the recommended security practice that ``username`` and

-``password`` are specified. You cannot provide the ``delivery_url`` in

-your dmaap-file, because it’s not constructed until deployment time.

-Therefore, after the test deployment, go back to the Data Router Feed

-and provide the delivery_url (in order to start receiving the feeds).

-

-Data Router Example

-~~~~~~~~~~~~~~~~~~~

-

-(After the Data Router feed has been manually provisioned)

-

-::

 

-    $ dcae_cli component run --dmaap-file $dmaap_file $component-name

-    DCAE.Run | WARNING | Your component is a data router subscriber. Here are the delivery urls:

 

-            some-sub-dr: http://135.205.226.128:32838/identity

 

-(Update the Data Router Feed to provide the delivery_url).

diff --git a/docs/sections/components/component-specification/docker-specification.rst b/docs/sections/design-components/component-specification/docker-specification.rst
index 128c006d..6dd4f927 100755
--- a/docs/sections/components/component-specification/docker-specification.rst
+++ b/docs/sections/design-components/component-specification/docker-specification.rst
@@ -1,19 +1,18 @@
 .. This work is licensed under a Creative Commons Attribution 4.0 International License.

 .. http://creativecommons.org/licenses/by/4.0

 

-.. _docker-specification:

+.. _docker-requirements:

 

-Component specification (Docker)

-================================

+Component Spec Requirements

+===========================

 

-The Docker component specification contains the following groups of

-information. Many of these are common to both Docker and CDAP components

-and are therefore described in the common specification.

+The component specification contains the following groups of

+information. 

 

 -  :any:`Metadata <metadata>`

 -  :any:`Interfaces <interfaces>` including the

    associated :any:`Data Formats <data-formats>`

--  :any:`Parameters <parameters>`

+-  :any:`Parameters <common-specification-parameters>`

 -  :any:`Auxiliary Details <docker-auxiliary-details>`

 -  :any:`List of Artifacts <artifacts>`

 

@@ -24,7 +23,7 @@ Auxiliary Details
 

 ``auxiliary`` contains Docker specific details like health check, port

 mapping, volume mapping and policy reconfiguration script details.

-(Policy reconfiguration is not yet supported).

+

 

 +--------------------------------+---------+---------------------------+

 | Name                           | Type    | Description               |

@@ -42,8 +41,6 @@ mapping, volume mapping and policy reconfiguration script details.
 |                                |         | object. See example       |

 |                                |         | below.                    |

 +--------------------------------+---------+---------------------------+

-| *Planned for 1806*             |         |                           |

-+--------------------------------+---------+---------------------------+

 | policy                         | JSON    | *Required*. Policy        |

 |                                | array   | reconfiguration script    |

 |                                |         | details                   |

@@ -52,13 +49,10 @@ mapping, volume mapping and policy reconfiguration script details.
 Health Check Definition

 ~~~~~~~~~~~~~~~~~~~~~~~

 

-The platform uses Consul to perform periodic health check calls. Consul

-provides different types of `check

-definitions <https://www.consul.io/docs/agent/checks.html>`__. The

-platform currently supports http and docker health checks.

+The platform currently supports http and docker script based health checks. 

 

 When choosing a value for interval, consider that too frequent

-healthchecks will put unnecessary load on Consul and DCAE. If there is a

+healthchecks will put unnecessary load on the platform. If there is a

 problematic resource, then more frequent healthchecks are warranted (eg

 15s or 60s), but as stability increases, so can these values, (eg

 300s).

@@ -84,8 +78,7 @@ http
 +--------------------------------+---------+---------------------------+

 | endpoint                       | string  | *Required*. GET endpoint  |

 |                                |         | provided by the component |

-|                                |         | for Consul to call to     |

-|                                |         | check health              |

+|                                |         | for checking health       |

 +--------------------------------+---------+---------------------------+

 

 Example:

@@ -121,9 +114,12 @@ docker script example
 |                                |         | executed                  |

 +--------------------------------+---------+---------------------------+

 

-Consul will use the `Docker exec

-API <https://docs.docker.com/engine/api/v1.29/#tag/Exec>`__ to

-periodically call your script in your container. It will examine the

+During deployment, the K8S plugin maps the healthcheck defined into 

+into a Kubernetes readiness probe.  

+

+Kubernetes execs the script in the container (using the `docker exec API

+ <https://docs.docker.com/engine/api/v1.29/#tag/Exec>`__ ). 

+It will examine the

 script result to identify whether your component is healthy. Your

 component is considered healthy when the script returns ``0`` otherwise

 your component is considered not healthy.

@@ -232,8 +228,8 @@ In the example above, the container volume “/tmp/docker.sock” maps to
 host volume “/var/run/docker.sock”.

 

 

-Policy (not yet supported)

-~~~~~~~~~~~~~~~~~~~~~~~~~~

+Policy 

+~~~~~~~

 

 Policy changes made in the Policy UI will be provided to the Docker

 component by triggering a script that is defined here.

diff --git a/docs/sections/components/component-specification/component-specification.rst b/docs/sections/design-components/component-specification/index-component-specification.rst
index 56649d31..76ef2129 100644
--- a/docs/sections/components/component-specification/component-specification.rst
+++ b/docs/sections/design-components/component-specification/index-component-specification.rst
@@ -7,10 +7,9 @@ Component Specification
 .. toctree::
    :maxdepth: 1
 
-   ./common-specification.rst
-   ./cdap-specification.rst
+   ./component-type-docker.rst
+   ./component-json-schema.rst   
    ./docker-specification.rst
    ./dmaap-connection-objects.rst
    ./streams-grid.rst
-   ./configuration-grid.rst
-
+   ./configuration-grid.rst
\ No newline at end of file
diff --git a/docs/sections/components/component-specification/streams-grid.rst b/docs/sections/design-components/component-specification/streams-grid.rst
index 6105e9e1..6105e9e1 100755
--- a/docs/sections/components/component-specification/streams-grid.rst
+++ b/docs/sections/design-components/component-specification/streams-grid.rst
diff --git a/docs/sections/DCAE-MOD/Glossary.rst b/docs/sections/design-components/glossary.rst
index b4c2beb2..b1430e22 100644
--- a/docs/sections/DCAE-MOD/Glossary.rst
+++ b/docs/sections/design-components/glossary.rst
@@ -1,8 +1,11 @@
-========
+
+.. http://creativecommons.org/licenses/by/4.0
+
+.. _glossary:
+
 Glossary
 ========
 
-
 A&AI - Active and Available Inventory
 -------------------------------------
 Inventory DB for all network components
@@ -26,8 +29,7 @@ Cloudify
 --------
 Open Source application and network orchestration framework, based on
 TOSCA used in DCAE to deploy platform and service components from
-Cloudify Blueprints. Refer to `Architecture </architecture/pieces>`__
-for more information.
+Cloudify Blueprints. 
 
 
 Cloudify Blueprints
@@ -73,8 +75,8 @@ Cloudify to deploy components.
 
 Design-Time
 -----------
-Refers to when the System Designer uses the SDC Tool to compose services
-from components in the SDC catalog. The Designer can provide input to
+Refers to when the System Designer uses a design tool to compose services
+from components in the catalog. The Designer can provide input to
 assign/override defaults for configuration for any parameter with the
 property 'designer\_editable' set to 'true'.
 
@@ -138,19 +140,9 @@ Inventory
 
 SDC - Service Design and Creation
 ---------------------------------
-Tool used by Service Designers to compose services from SDC catalog
-artifacts. Once services are created, Cloudify Blueprints can be
-generated to deployment and installation.
+ONAP design catalog for onboarding VNF/PNF packages
 
 
-SDC Catalog
------------
-Catalog of composable Components and Data Formats to be used in the SDC
-Tool to create services. Currently, there is no access to the SDC
-Catalog from the dcae\_cli tool. Artifacts are manually placed there
-after testing. Every catalog artifact has a ``UUID``, a globally unique
-identifier that identifies that artifact.
-
 Self-Service
 ------------
 Refers to services that are supported by SDC, and that are automatically
@@ -172,13 +164,6 @@ Generally composed of multiple service components, which is deployed to
 the DCAE platform.
 
 
-Tosca Model
------------
-Model generated from validated component specification, (stored in SDC
-catalog for Self-Service components), and used as input to generate
-Cloudify Blueprints
-
-
 VNF - Virtualized Network Function
 ----------------------------------
 A network function that runs on one or more virtualized machines.
diff --git a/docs/sections/images/1.png b/docs/sections/design-components/images/1.png
index e734a673..e734a673 100644
--- a/docs/sections/images/1.png
+++ b/docs/sections/design-components/images/1.png
diff --git a/docs/sections/images/10.png b/docs/sections/design-components/images/10.png
index 9a7f75ad..9a7f75ad 100644
--- a/docs/sections/images/10.png
+++ b/docs/sections/design-components/images/10.png
diff --git a/docs/sections/images/11.png b/docs/sections/design-components/images/11.png
index fe5ed014..fe5ed014 100644
--- a/docs/sections/images/11.png
+++ b/docs/sections/design-components/images/11.png
diff --git a/docs/sections/images/12.png b/docs/sections/design-components/images/12.png
index f2d5a360..f2d5a360 100644
--- a/docs/sections/images/12.png
+++ b/docs/sections/design-components/images/12.png
diff --git a/docs/sections/images/13.png b/docs/sections/design-components/images/13.png
index c63d1361..c63d1361 100644
--- a/docs/sections/images/13.png
+++ b/docs/sections/design-components/images/13.png
diff --git a/docs/sections/images/14.png b/docs/sections/design-components/images/14.png
index 5b507b10..5b507b10 100644
--- a/docs/sections/images/14.png
+++ b/docs/sections/design-components/images/14.png
diff --git a/docs/sections/images/15.png b/docs/sections/design-components/images/15.png
index 1529ef04..1529ef04 100644
--- a/docs/sections/images/15.png
+++ b/docs/sections/design-components/images/15.png
diff --git a/docs/sections/images/16.png b/docs/sections/design-components/images/16.png
index e3a7e36d..e3a7e36d 100644
--- a/docs/sections/images/16.png
+++ b/docs/sections/design-components/images/16.png
diff --git a/docs/sections/images/17.png b/docs/sections/design-components/images/17.png
index 54347d18..54347d18 100644
--- a/docs/sections/images/17.png
+++ b/docs/sections/design-components/images/17.png
diff --git a/docs/sections/images/18.png b/docs/sections/design-components/images/18.png
index 150e1c61..150e1c61 100644
--- a/docs/sections/images/18.png
+++ b/docs/sections/design-components/images/18.png
diff --git a/docs/sections/images/19.png b/docs/sections/design-components/images/19.png
index b578b103..b578b103 100644
--- a/docs/sections/images/19.png
+++ b/docs/sections/design-components/images/19.png
diff --git a/docs/sections/images/2.png b/docs/sections/design-components/images/2.png
index 20bd7a01..20bd7a01 100644
--- a/docs/sections/images/2.png
+++ b/docs/sections/design-components/images/2.png
diff --git a/docs/sections/images/20.png b/docs/sections/design-components/images/20.png
index 80f56e92..80f56e92 100644
--- a/docs/sections/images/20.png
+++ b/docs/sections/design-components/images/20.png
diff --git a/docs/sections/images/21.png b/docs/sections/design-components/images/21.png
index c92a2346..c92a2346 100644
--- a/docs/sections/images/21.png
+++ b/docs/sections/design-components/images/21.png
diff --git a/docs/sections/images/22.png b/docs/sections/design-components/images/22.png
index bf4f1c02..bf4f1c02 100644
--- a/docs/sections/images/22.png
+++ b/docs/sections/design-components/images/22.png
diff --git a/docs/sections/images/23.png b/docs/sections/design-components/images/23.png
index 98fd7970..98fd7970 100644
--- a/docs/sections/images/23.png
+++ b/docs/sections/design-components/images/23.png
diff --git a/docs/sections/images/24.png b/docs/sections/design-components/images/24.png
index 2784fddf..2784fddf 100644
--- a/docs/sections/images/24.png
+++ b/docs/sections/design-components/images/24.png
diff --git a/docs/sections/images/25.png b/docs/sections/design-components/images/25.png
index 55464c46..55464c46 100644
--- a/docs/sections/images/25.png
+++ b/docs/sections/design-components/images/25.png
diff --git a/docs/sections/images/26.png b/docs/sections/design-components/images/26.png
index 9486bb80..9486bb80 100644
--- a/docs/sections/images/26.png
+++ b/docs/sections/design-components/images/26.png
diff --git a/docs/sections/images/27.png b/docs/sections/design-components/images/27.png
index 3c0bd2f3..3c0bd2f3 100644
--- a/docs/sections/images/27.png
+++ b/docs/sections/design-components/images/27.png
diff --git a/docs/sections/images/3.png b/docs/sections/design-components/images/3.png
index 7d1d9df0..7d1d9df0 100644
--- a/docs/sections/images/3.png
+++ b/docs/sections/design-components/images/3.png
diff --git a/docs/sections/images/4.png b/docs/sections/design-components/images/4.png
index 69706f63..69706f63 100644
--- a/docs/sections/images/4.png
+++ b/docs/sections/design-components/images/4.png
diff --git a/docs/sections/images/5.png b/docs/sections/design-components/images/5.png
index ec158035..ec158035 100644
--- a/docs/sections/images/5.png
+++ b/docs/sections/design-components/images/5.png
diff --git a/docs/sections/images/6.png b/docs/sections/design-components/images/6.png
index b3f7e7bc..b3f7e7bc 100644
--- a/docs/sections/images/6.png
+++ b/docs/sections/design-components/images/6.png
diff --git a/docs/sections/images/7.png b/docs/sections/design-components/images/7.png
index adb8a941..adb8a941 100644
--- a/docs/sections/images/7.png
+++ b/docs/sections/design-components/images/7.png
diff --git a/docs/sections/images/8.png b/docs/sections/design-components/images/8.png
index e04c60ed..e04c60ed 100644
--- a/docs/sections/images/8.png
+++ b/docs/sections/design-components/images/8.png
diff --git a/docs/sections/images/9.png b/docs/sections/design-components/images/9.png
index c18e9487..c18e9487 100644
--- a/docs/sections/images/9.png
+++ b/docs/sections/design-components/images/9.png
diff --git a/docs/sections/images/DCAE-Mod-Architecture.png b/docs/sections/design-components/images/DCAE-Mod-Architecture.png
index ce5fca92..ce5fca92 100644
--- a/docs/sections/images/DCAE-Mod-Architecture.png
+++ b/docs/sections/design-components/images/DCAE-Mod-Architecture.png
diff --git a/docs/sections/images/Onboarding-with-DCAE-MOD.png b/docs/sections/design-components/images/Onboarding-with-DCAE-MOD.png
index 4883b65e..4883b65e 100644
--- a/docs/sections/images/Onboarding-with-DCAE-MOD.png
+++ b/docs/sections/design-components/images/Onboarding-with-DCAE-MOD.png
diff --git a/docs/sections/images/nifi-toolbar-components.png b/docs/sections/design-components/images/nifi-toolbar-components.png
index fa90afef..fa90afef 100644
--- a/docs/sections/images/nifi-toolbar-components.png
+++ b/docs/sections/design-components/images/nifi-toolbar-components.png
diff --git a/docs/sections/design-components/index-onboarding.rst b/docs/sections/design-components/index-onboarding.rst
new file mode 100644
index 00000000..1e859d1b
--- /dev/null
+++ b/docs/sections/design-components/index-onboarding.rst
@@ -0,0 +1,18 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
+Design Platform
+===============
+
+.. toctree::
+   :maxdepth: 1
+
+   ./overview.rst
+   ./requirements-guidelines.rst
+   ./blueprint_generator.rst
+   ./DCAE-MOD/DCAE-MOD-Architecture.rst
+   ./component-specification/index-component-specification.rst
+   ./component-specification/data-formats.rst
+   ./DCAE-MOD/DCAE-MOD-User-Guide.rst
+   ./glossary.rst
+   
\ No newline at end of file
diff --git a/docs/sections/components/intro.rst b/docs/sections/design-components/overview.rst
index db7175c1..654a0c11 100755
--- a/docs/sections/components/intro.rst
+++ b/docs/sections/design-components/overview.rst
@@ -12,11 +12,34 @@ are generally written to be composable with other DCAE components,
 although a component can run independently as well. The DCAE platform is

 responsible for running and managing DCAE service components reliably.

 

-Currently, the DCAE platform supports two types of components, CDAP

-applications and Docker containers. For each, there are requirements

-that must be met for the component to integrate into the DCAE platform

-(see :doc:`CDAP <component-type-cdap>` and

-:doc:`Docker <component-type-docker>`).

+The DCAE Design platform aims to provide a common catalog of available DCAE 

+Service components, enabling designers to select required 

+components to construct and deploy composite flows into DCAE Runtime platform.

+

+Service component/MS to be onboarded and deployed into DCAE platform would 

+typically go through the following phases

+

+ - Onboarding 

+ - Design 

+ - Runtime

+

+DCAE Design Platform supports onboarding and service design through MOD. 

+

+

+Onboarding is a process that ensures that the component is compliant

+with the DCAE platform rules. The high level summary of the onboarding process

+is:

+

+1. Defining the :doc:`data formats <data-formats>` if they don’t already

+   exist. 

+2. Defining the :doc:`component specification <./component-specification/component-specification>`

+3. Validate the component spec schema against

+   `Component Spec json schema <https://git.onap.org/dcaegen2/platform/plain/mod/component-json-schemas/component-specification/dcae-cli-v2/component-spec-schema.json>`__

+4. Use  :doc:`blueprint-generator tool <./blueprint_generator>` to generate Cloudify blueprint

+5. Test the blueprint generated in DCAE Runtime Environment (using either Dashboard UI or Cloudify cli from bootstrap)

+6. Using :doc:`DCAE-MOD <../DCAE-MOD/DCAE-MOD-User-Guide>` , publish the component and data formats into DCAE-MOD catalog. 

+   (This step is required if Microservice needs to be deployed part of flow/usecase)

+

 

 A Component requires one or more data formats.

 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

@@ -43,7 +66,8 @@ Each Component requires a component specification.
 

 The component specification is a JSON artifact that fully specifies the

 component, it’s interfaces, and configuration. It’s standardized for

-CDAP and Docker applications and is validated using a :doc:`JSON schema <./component-json-schema>`.

+CDAP (deprecated) and Docker applications and is validated using a 

+:doc:`JSON schema <./component-specification/component-json-schema>`.

 

 The component specification fully specifies all the configuration

 parameters of the component. This is used by the designer and by policy

@@ -65,41 +89,19 @@ blueprints.
 

 The component specification is used by:

 

--  dcae_cli tool - to validate it

--  Design Tools - TOSCA models are generated from the component

-   specification so that the component can be used by designers to

-   compose new DCAE services in SDC.

+

+-  Blueprint Generator - Tool to generate standalone cloudify blueprint

+   using component spec. The blueprints can be uploaded into inventory 

+   using Dashboard and triggered for deployment.

+-  MOD Platform - To onboard the microservice and maintain in catalog

+   enabling designer to compose new DCAE service flows and distribute

+   to DCAE Runtime platform.

 -  Policy (future) - TOSCA models are generated from the component

    specification so that operations can create policy models used to

    dynamically configure the component.

--  the runtime platform - The component’s application configuration

+-  Runtime platform - The component’s application configuration

    (JSON) is generated from the component specification and will be

-   provided to the component at runtime.

-

-Onboarding

-----------

+   provided to the component at runtime (through ConfigBindingService

+   or Consul).

 

-Onboarding is a process that ensures that the component is compliant

-with the DCAE platform rules. A command-line tool called

-:doc:`dcae-cli <./dcae-cli/quickstart>` is provided to

-help with onboarding. The high level summary of the onboarding process

-is:

-

-1. Defining the :doc:`data formats <data-formats>` if they don’t already

-   exist.

-2. Defining the :doc:`component specification <./component-specification/common-specification>`.

-   See :doc:`docker <./component-specification/docker-specification>` and

-   :doc:`CDAP <./component-specification/cdap-specification>`.

-3. Use the dcae_cli tool to :any:`add the data formats <dcae_cli_add_a_data_format>` and

-   :any:`add the component <dcae_cli_add_a_component>` to the

-   onboarding catalog. This process will validate them as well.

-4. Use the dcae_cli tool to

-   :any:`deploy <dcae_cli_run_a_component>` the

-   component. (The component is deployed to the environment indicated in

-   the :any:`profile <dcae_cli_activate_profile>`

-   section).

-5. Test the component. Also do pairwise-test the component with any

-   other components it connects with.

-6. Publish the component and data formats into the Service Design and

-   Creation (SDC) ‘catalog’. (Currently, this is a manual step, not done

-   via the dcae_cli tool).

+   
\ No newline at end of file
diff --git a/docs/sections/design-components/requirements-guidelines.rst b/docs/sections/design-components/requirements-guidelines.rst
new file mode 100644
index 00000000..f633178c
--- /dev/null
+++ b/docs/sections/design-components/requirements-guidelines.rst
@@ -0,0 +1,279 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
+Onboarding Pre-requisite
+========================
+
+Before a component is onboarded into DCAE, the component developer must ensure it 
+is compliant with ONAP & DCAE goals and requirement in order to correctly be deployed and be managed. This
+page will discuss the changes which are grouped into the following
+categories:
+
+-  :any:`Configuration management via ConfigBindingService <configuration_management>`
+-  :any:`Docker images <docker_images>`
+-  :any:`Policy Reconfiguration flow support <policy_reconfiguration>`
+-  :any:`Operational Requirement <operation_requirement>`
+
+
+.. _configuration_management:
+
+Configuration Management
+------------------------
+
+All configuration for a component is stored in CONSUL under the
+components uniquely generated name which is provided by the environment
+variable ``HOSTNAME`` as well as ``SERVICE_NAME``. It is then made
+available to the component via a remote HTTP service call to CONFIG
+BINDING SERVICE.
+
+The main entry in CONSUL for the component contains its
+**generated application configuration**. This is based on the submitted
+component specification, and consists of the *interfaces* (streams and
+services/calls) and *parameters* sections. Other entries may exist as
+well, under specific keys, such as :dmaap . Each key represents a
+specific type of information and is also available to the component by
+calling CONFIG BINDING SERVICE. More on this below.
+
+Components are required to pull their
+**generated application configuration** at application startup using the environment
+setting exposed during deployment. 
+
+ 
+Envs
+~~~~
+
+The platform provides a set of environment variables into each Docker
+container:
+
++----------------------------+--------------+----------------------------------------+
+| Name                       | Type         | Description                            |
++============================+==============+========================================+
+| ``HOSTNAME``               | string       | Unique name of the component instance  |
+|                            |              | that is generated                      |
++----------------------------+--------------+----------------------------------------+
+| ``CONSUL_HOST``            | string       | Hostname of the platform's Consul      |
+|                            |              | instance                               |
++----------------------------+--------------+----------------------------------------+
+| ``CONFIG_BINDING_SERVICE`` | string       | Hostname of the platform's config      |
+|                            |              | binding service instance               |
+|                            |              |                                        |
++----------------------------+--------------+----------------------------------------+
+| ``DOCKER_HOST``            | string       | Host of the target platform Docker     |
+|                            |              | host to run the container on           |
++----------------------------+--------------+----------------------------------------+
+| ``CBS_CONFIG_URL``         | string       | Fully resolved URL to query config     |
+|                            |              | from CONSUL via CBS                    |
++----------------------------+--------------+----------------------------------------+
+
+
+.. _config_binding_service:
+
+Config Binding Service
+~~~~~~~~~~~~~~~~~~~~~~
+
+The config binding service is a platform HTTP service that is
+responsible for providing clients with its fully resolve configuration
+JSON at startup, and also other configurations objects 
+when requested.
+
+At runtime, components should make an HTTP GET on:
+
+::
+  
+  <config binding service hostname>:<port>/service_component/NAME
+
+For Docker components, NAME should be set to ``HOSTNAME``, which is
+provided as an ENV variable to the container.
+
+The binding service integrates with the streams and services section of
+the component specification. For example, if you specify that you call a
+service:
+
+::
+
+    "services": {
+        "calls": [{
+            "config_key": "vnf-db",
+            "request": {
+                "format": "dcae.vnf.meta",
+                "version": "1.0.0"
+                },
+            "response": {
+                "format": "dcae.vnf.kpi",
+                "version": "1.0.0"
+                }
+        }],
+    ...
+    }
+
+Then the config binding service will find all available IP addresses of
+services meeting the containers needs, and provide them to the container
+under your ``config_key``:
+
+::
+
+    // your configuration
+    {
+        "vbf-db" :                 // see above 
+            [IP:Port1, IP:Port2,…] // all of these meet your needs, choose one.
+    }
+
+Regarding ``<config binding service hostname>:<port>``, there is DNS
+work going on to make this resolvable in a convenient way inside of your
+container. 
+
+For all Kubernetes deployments since El-Alto, an environment variable ``CBS_CONFIG_URL`` will be exposed 
+by platform (k8s plugins) providing the exact URL to be used for configuration retrieval. 
+Application can use this URL directly instead of constructing URL from HOSTNAME (which refers to ServiceComponentName) 
+and CONFIG_BINDING_SERVICE env's.  By default, this URL will use HTTPS CBS interface
+
+If you are integrating with CBS SDK, then the DNS resolution and configuration fetch 
+are handled via library functions.
+
+Generated Application Configuration
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The DCAE platform uses the component specification to generate the
+component’s application configuration provided at deployment time. The
+component developer should expect to use this configuration JSON in the
+component.
+
+
+The following component spec snippet (from String Matching):
+
+::
+
+    "streams":{  
+        "subscribes": [{
+          "format": "VES_specification",  
+          "version": "4.27.2",    
+          "type": "message_router",
+          "config_key" : "mr_input"
+        }],
+        "publishes": [{
+          "format": "VES_specification",  
+          "version": "4.27.2",    
+          "config_key": "mr_output",
+          "type": "message_router"
+         }]
+      },
+      "services":{  
+        "calls": [{
+          "config_key" : "aai_broker_handle",
+          "verb": "GET",
+          "request": {
+            "format": "get_with_query_params",
+            "version": "1.0.0"
+          },
+          "response": {
+            "format": "aai_broker_response",
+            "version": "3.0.0"
+          } 
+        }],
+        "provides": []
+      },
+
+Will result in the following top level keys in the configuration
+
+::
+
+       "streams_publishes":{  
+          "mr_output":{                // notice the config key above
+             "aaf_password":"XXX",
+             "type":"message_router",
+             "dmaap_info":{  
+                "client_role": null,
+                "client_id": null,
+                "location": null,
+                "topic_url":"https://YOUR_HOST:3905/events/com.att.dcae.dmaap.FTL2.DCAE-CL-EVENT" // just an example
+             },
+             "aaf_username":"XXX"
+          }
+       },
+       "streams_subscribes":{  
+          "mr_input":{                 // notice the config key above
+             "aaf_password":"XXX",
+             "type":"message_router",
+             "dmaap_info":{  
+                "client_role": null,
+                "client_id": null,
+                "location": null,
+                "topic_url":"https://YOUR_HOST:3905/events/com.att.dcae.dmaap.FTL2.TerrysStringMatchingTest" // just an example
+             },
+             "aaf_username":"XXX"
+          }
+       },
+       "services_calls":{  
+          "aai_broker_handle":[        // notice the config key above
+             "135.205.226.128:32768"   // based on deployment time, just an example
+          ]
+       }
+
+These keys will always be populated whether they are empty or not. So
+the minimum configuration you will get, (in the case of a component that
+provides an HTTP service, doesn’t call any services, and has no streams,
+is:
+
+::
+
+        "streams_publishes":{},
+        "streams_subscribes":{},
+        "services_calls":{}
+
+Thus your component should expect these well-known top level keys.
+
+DCAE SDK
+~~~~~~~~
+
+DCAE has SDK/libraries which can be used for service components for easy integration.
+
+- `Java Library <https://docs.onap.org/en/latest/submodules/dcaegen2.git/docs/sections/sdk/architecture.html>`__
+- `Python Modules <https://git.onap.org/dcaegen2/utils/tree/onap-dcae-cbs-docker-client>`__
+
+
+
+.. _policy_reconfiguration:
+
+Policy Reconfiguration
+----------------------
+
+Components must provide a way to receive policy reconfiguration, that
+is, configuration parameters that have been updated via the Policy UI.
+The component developer must either periodically poll the ConfigBindingService API
+to retrieve/refresh the new configuration or provides a script (defined in the :any:`Docker
+auxiliary specification <docker-auxiliary-details>`)
+that will be triggered when policy update is detected by the platform.
+
+
+.. _docker_images:	
+
+Docker Images
+-------------
+
+Docker images must be pushed to the environment specific Nexus
+repository. This requires tagging your build with the full name of you
+image which includes the Nexus repository name.
+
+For ONAP microservices, the components images are expected to pushed into ONAP nexus
+part of `ONAP CI jobs <https://wiki.onap.org/display/DW/Using+Standard+Jenkins+Job+%28JJB%29+Templates>`__
+
+
+.. _operation_requirement:
+
+Operational Requirement
+-----------------------
+
+Logging
+~~~~~~~
+
+All ONAP MS logging should follow logging specification defined by `logging project <https://wiki.onap.org/pages/viewpage.action?pageId=71831691>`__
+
+The application log configuration must enable operation to choose if to be written into file or stdout or both during deployment.
+
+
+S3P 
+~~~
+ONAP S3P (all scaling/resiliency/security/maintainability) goals should meet at the minimum level defined for DCAE project for the targeted release 
+
+If the component is stateful, it should persist its state on external store (eg. pg, redis) to allow support for scaling and resiliency. This should be important design criteria for the component. If the components either publish/subscribe into DMAAP topic, then secure connection to DMAAP must be supported (platform will provide aaf_username/aaf_password for each topic as configuration).
+
diff --git a/docs/sections/release-notes.rst b/docs/sections/release-notes.rst
index 849cd7b7..495f5918 100644
--- a/docs/sections/release-notes.rst
+++ b/docs/sections/release-notes.rst
@@ -3,11 +3,23 @@
 .. Copyright (c) 2017-2020 AT&T Intellectual Property. All rights reserved.
 .. _release_notes:
 
+
+
+==================
 DCAE Release Notes
 ==================
 
+.. contents::
+    :depth: 2
+..
+
+
+Version: 6.0.0
+==============
+
 Abstract
 --------
+
 This document provides the release notes for the Frankfurt release (6.0.0)
 
 
@@ -16,9 +28,10 @@ Summary
 
 **New Features**
 
-DCAE improves upon previous release with the following new features:
+DCAE improves upon previous release with the following new features
 
 - DCAE Platform Enhancement
+
     - Introduction of Microservice and Onboarding Design (MOD) platform 
     - Policy Notification support for DCAE components
     - Dynamic AAF certificate creation during component instantiation
@@ -27,16 +40,22 @@ DCAE improves upon previous release with the following new features:
     - Blueprint generator tool to simplify deployment artifact creation
    
 
-- Following new services are delivered with Frankfurt
+- Following new services are delivered this release
+
     - Event Processors
+    
         - PM Subscription Handler
         - DataLake Handlers 
     - Analytics/RCA
+    
         - TCA-GEN2
+	
 	- Acumos Adapter (PoC)
  
-Following is complete list of DCAE components available part of default ONAP/DCAE installation.
+Below is complete list of DCAE components available part of default ONAP/DCAE installation.
+
     - Platform components
+
         - Cloudify Manager (helm chart)
         - Bootstrap container (helm chart)
         - Configuration Binding Service (helm chart)
@@ -45,7 +64,9 @@ Following is complete list of DCAE components available part of default ONAP/DCA
         - Service Change Handler (helm chart)
         - Inventory API (helm chart)
         - Dashboard (helm chart)
+
     - Service components
+
         - VES Collector
         - Threshold Crossing Analytics (TCA/CDAP)
         - HV-VES Collector
@@ -53,13 +74,16 @@ Following is complete list of DCAE components available part of default ONAP/DCA
         - Docker based Threshold Crossing Analytics (TCA-Gen2)
         - Holmes Rule Management *
         - Holmes Engine Management *
+
     - Additional resources that DCAE utilizes deployed using ONAP common charts:
+    
         - Postgres Database
         - Mongo Database
         - Redis Cluster Database
         - Consul Cluster 
 
-Following are service components (mS) which can be deployed on-demand
+Following service components (mS) can be deployed on-demand
+
  	- SNMPTrap Collector
  	- RESTConf Collector
  	- DataFile Collector
@@ -71,6 +95,7 @@ Following are service components (mS) which can be deployed on-demand
  	- PM-Subscription Handler
 
     Notes:
+
         \*  These components are delivered by the Holmes project.
 
 
@@ -84,6 +109,7 @@ Under OOM (Kubernetes) deployment all DCAE component containers are deployed as
 **Bug Fixes**
 
 **Known Issues**
+
     * Blueprint generator issue (DCAEGEN2-2140)
     * TCAgen2 Policy configuration support (DCAEGEN2-2198)
 
@@ -152,8 +178,8 @@ Artifacts released:
    "dcaegen2/services/mapper", "", "onap/org.onap.dcaegen2.services.mapper.vesadapter.universalvesadaptor:1.0.1"
    "dcaegen2/services/pm-mapper", "", "onap/org.onap.dcaegen2.services.pm-mapper:1.3.1"
    "dcaegen2/services/prh", "", "onap/org.onap.dcaegen2.services.prh.prh-app-server:1.5.2"
-   "dcaegen2/services/son-handler", "", "onap/org.onap.dcaegen2.services.son-handler:2.0.0"
-   "dcaegen2/platform", "adapter/acumos", "onap/org.onap.dcaegen2.platform.adapter.acumos:1.0.1"
+   "dcaegen2/services/son-handler", "", "onap/org.onap.dcaegen2.services.son-handler:2.0.2"
+   "dcaegen2/platform", "adapter/acumos", "onap/org.onap.dcaegen2.platform.adapter.acumos:1.0.2"
    "dcaegen2/platform", "mod/bpgenerator", "Blueprint Generator 1.3.1 (jar)"
    "dcaegen2/services/sdk", "", "DCAE SDK 1.3.5 (jar)"
    "ccsdk/dashboard", "", "onap/org.onap.ccsdk.dashboard.ccsdk-app-os:1.3.2"
@@ -165,11 +191,12 @@ Artifacts released:
 
 
 **References**
+
         - `DCAE project page <https://wiki.onap.org/display/DW/Data+Collection+Analytics+and+Events+Project>`_
         - `Passing Badge information for DCAE <https://bestpractices.coreinfrastructure.org/en/projects/1718>`_
 
 Version: 5.0.1
---------------
+==============
 
 The offical El-Alto release (rolls up all 5.0.0 early drop deliverables) focused on technical debts and SECCOM priority work-items.
 
@@ -332,7 +359,7 @@ The following components are upgraded from Dublin/R4 and El-Alto EarlyDrop deliv
        - Description : Code optimization, bug fixes and SDK alignment
 
 Version: 5.0.0
---------------
+==============
 
 El-Alto Early-drop focused on technical debts and SECCOM priority work-items.
 
@@ -425,7 +452,7 @@ The following components are upgraded from Dublin/R4.
 
 
 Version: 4.0.0
---------------
+==============
 
 :Release Date: 2019-06-06
 
@@ -627,7 +654,7 @@ The following components are upgraded from R3
 
 
 Version: 3.0.1
---------------
+==============
 
 :Release Date: 2019-01-31
 
@@ -814,7 +841,7 @@ The following components are upgraded from R2:
 
 
 Version: 2.0.0
---------------
+==============
 
 :Release Date: 2018-06-07
 
@@ -930,7 +957,7 @@ The following components are upgraded from R1:
 
 
 Version: 1.0.0
---------------
+==============
 
 :Release Date: 2017-11-16