...

The DCAE Controller includes following components. The platform components will be deployed via platform level blueprint (not handled through onboarding steps noted here).

-       Cloudify Manager

-       Consul

-       DeploymentHander

-       Policy-Handler

-       ServiceChangeHandler

-       Inventory-API

-       Postgres

-       Registrator

-       ConfigBinding Service

-       CDAP Broker

For component/MS to be deployed into DCAE platform would go through below phases

• Onboarding Phase
• Design Phase
• Runtime

Onboarding

During this phase, each of the component owner should create a meta data describing the components. There are two main artifacts required to be defined

...

Data formats are descriptions of data---they are the data contract between your component and other components. You need to describe the available outputs and assumed inputs of your components as data formats. These data descriptions are onboarded into SDC

Schema Definition

 data-format-schema.json

Example: VES-4.27.2-data-format

VES-4.27.2-dataformat.json

Component-spec

The component specification is a JSON that is used to describe and configure your component. The component specification contains the following top-level groups of information:

• Component metadata
• Component interfaces including the associated data formats
• Configuration parameters
• Auxiliary details
• List of artifacts 

            Schema Definition

component-spec-schema.json

      Example: VESCollector 

 vescollector-componentspec.json

The developers will upload the spec (data-formats, component spec) developed into catalog using dcae_cli/tosca tool. Once validated, spec’s will be published into SDC catalog so they can be used for service creation.

...

Design comprises of two steps.

Template creation

The TOSCA models generated from onboarding is used here to do this composition. Using SDC designer tool – individual reusable templates are created and stored in catalog.

Service Composition

Once the designer template is created, they can be used for Service composition (in SDC/CLAMP) to generate a Cloudify blueprint.

...

For Docker containers, the configuration identified part of MS component-spec is retrieved from Configbinding service during application start-up and when notified by controller on a configuration change. The docker container part of init script - should query configbindingservice and fetch the configuration.

Below is code snippet which does the configuration fetch in two steps

1) Identifies ConfigbindingService ip and port by querying Consul

2) Queries ConfigbindingService and retrieves the configuration into a file.

The data is represented as key-value pair is gets written into a file within container above. The Docker MS should parse the configuration and apply within MS as required.

...

The dmaap topic stream are identified in compenent_spec as "subcribesubscribe" and "publish" streams. Each unique topic should be identified by the component developer using unique config_key.  When the configuration gets pushed into the container by controller, the topic configuration is pushed under below structure.

"streams_publishes": {

"config_key1": {

          "type": "message_router",
                "aaf_password": "value",
                "dmaap_info": {
                    "location": "xxloc",
                    "client_id": "111111id",
                    "client_role": "aafrole",
                    "topic_url": "topic-url"
                },
                "aaf_username": "user"

...