DCAE Controller documentation DCAEGEN2-213

Issue-ID: DCAEGEN2-213
Change-Id: I7f2023b7f88b73eef852eca0bbf9086e14903cd6
Signed-off-by: Ralph Knag <rhknag@research.att.com>

1 files changed, 97 insertions, 0 deletions

diff --git a/docs/sections/components/intro.rst b/docs/sections/components/intro.rst
new file mode 100755
index 00000000..8a31e844
--- /dev/null
+++ b/docs/sections/components/intro.rst
@@ -0,0 +1,97 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.

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

+

+.. _intro:

+

+

+Component Developer Overview

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

+

+DCAE components are services that provide a specific functionality and

+are written to be composable with other DCAE service components. 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>`.

+

+Components requires one or more data formats.

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

+

+Components are software applications that do some function. Components

+don’t run independently, they depend upon other components. A

+component’s function could require connecting to other components to

+fulfill that function. A component could also be providing its function

+as a service through an interface for other components to use.

+

+Components cannot connect to or be connected with any other component.

+The upstream and downstream components must *speak* the same vocabulary

+or *data format*. The output of an one component must match another

+component’s input. This is necessary for components to function

+correctly and without errors.

+

+The platform requires data formats to ensure that a component will be

+run with other *compatible* components.

+

+Data formats can and should be shared by multiple components.

+

+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 :any:`JSON

+schema <dcae-component-schema>`.

+

+The component specification fully specifies all the configuration

+parameters of the component. This is used by the designer and by policy

+(future) to configure the runtime behavior of the component.

+

+The component specification is used to *generate* application

+configuration in a standardized JSON that the platform will make

+available to the component. This application configuration JSON will

+include:

+

+-  Parameters that have been assigned values from the component

+   specification, policy, and/or the designer

+-  Connection details of downstream components

+

+The component specification is transformed by DCAE tooling (explained

+later) into TOSCA models (one for the component, and in the future, one

+for Policy). The TOSCA models then get transformed into Cloudify

+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.

+-  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

+   (JSON) is generated from the component specification and will be

+   provided to the component at runtime.

+

+Onboarding

+----------

+

+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. Define 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 <adding-data-formats>`

+   and :any:`add the component <adding-component>` to

+   the onboarding catalog. This process will validate them as well.

+4. Use the dcae_cli tool to :any:`deploy <development-and-testing>`

+   the component. (The component is deployed to the environment

+   indicated in :any:`profile <setting-profile>`).

+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).