diff options
| author |   VENKATESH KUMAR <vv770d@att.com> | 2020-04-02 23:39:28 -0400 |
|---|---|---|
| committer | VENKATESH KUMAR <vv770d@att.com> | 2020-04-02 23:48:26 -0400 |
| commit | c790dcb3bbd3c498e0f838837c212ce185e70da5 (patch) | |
| tree | cbde7e82480efbdc3a26844e2e03bf4806aeaaa8 | |
| parent | cfb11090aa5fbcb7d38870cdeeb7c21e48b077df (diff) | |
dcae doc cleanup
Remove old markdown platform doc
Change-Id: I592775a24d17d7d786708cde008703f4d899946c
Signed-off-by: VENKATESH KUMAR <vv770d@att.com>
Issue-ID: DCAEGEN2-1891
Signed-off-by: VENKATESH KUMAR <vv770d@att.com>
37 files changed, 12 insertions, 3107 deletions
diff --git a/docs/sections/release-notes.rst b/docs/sections/release-notes.rst index 2157b932..4c3b6744 100644 --- a/docs/sections/release-notes.rst +++ b/docs/sections/release-notes.rst @@ -28,7 +28,7 @@ DCAE R6 improves upon previous release with the following new features: - DataLake Handlers - Analytics/RCA - TCA-GEN2 -- Acumos Adapter (PoC) + - Acumos Adapter (PoC) Following is complete list of DCAE components available part of default ONAP/DCAE installation. - Platform components @@ -54,6 +54,17 @@ Following is complete list of DCAE components available part of default ONAP/DCA - Redis Cluster Database - Consul Cluster +Following are service components (mS) which can be deployed on-demand + - SNMPTrap Collector + - RESTConf Collector + - DataFile Collector + - PM-Mapper + - BBS-EventProcessor + - VES Mapper + - Heartbeat mS + - SON-Handler + - PM-Subscription Handler + Notes: \* These components are delivered by the Holmes project. @@ -65,36 +76,6 @@ Under OOM (Kubernetes) deployment all DCAE component containers are deployed as - All DCAE components are designed to support platform maturity requirements. -**Source Code** - -Source code of DCAE components are released under the following repositories on gerrit.onap.org: - - dcaegen2 - - dcaegen2.analytics.tca - - dcaegen2.collectors.snmptrap - - dcaegen2.collectors.ves - - dcaegen2.collectors.hv-ves - - dcaegen2.collectors.datafile - - dcaegen2.collectors.restconf - - dcaegen2.deployments - - dcaegen2.platform.blueprints - - dcaegen2.platform.cli - - dcaegen2.platform.configbinding - - dcaegen2.platform.deployment-handler - - dcaegen2.platform.inventory-api - - dcaegen2.platform.plugins - - dcaegen2.platform.policy-handler - - dcaegen2.platform.servicechange-handler - - dcaegen2.services.heartbeat - - dcaegen2.services.mapper - - dcaegen2.services.pm-mapper - - dcaegen2.services.prh - - dcaegen2.services.son-handler - - dcaegen2.services - - dcaegen2.services.sdk - - dcaegen2.utils - - ccsdk.platform.plugins - - ccsdk.dashboard - **Bug Fixes** **Known Issues** diff --git a/platformdoc/DCAE-DEPLOYMENT-GUIDE-1707.md b/platformdoc/DCAE-DEPLOYMENT-GUIDE-1707.md deleted file mode 100644 index 415fb2b6..00000000 --- a/platformdoc/DCAE-DEPLOYMENT-GUIDE-1707.md +++ /dev/null @@ -1,73 +0,0 @@ -### DCAE Controller - Deployment Guide 1707
-
-#### 1) Download latest deployer tar file to your cloudify bootstrap/cli server.
-
-Say, your working directory is ${WORKING-DIR}
-````
-cd ${WORKING-DIR}
-$ wget http://dockercentral.it.att.com:8093/nexus/repository/rawcentral/com.att.ecompcntr/opstools/dcae-deployer-5.0.tar
-$ tar -xvf dcae-deployer-5.0.tar
-$ cd ${WORKING-DIR}/dcae-deployer
-````
-#### 2) Clone the auto generated inputs files from code cloud and save it in <inputDirectory>
-````
-$ git clone ssh://<userid>@codecloud.web.att.com:7999/st_dcae/com.att.ecomp.dcae.operational.staging.ftl.git <inputsDirectory>
-
-````
-#### 3) Clone the latest consulAgent.sh
-````
-$ git clone ssh://git@codecloud.web.att.com:7999/st_ecompcntr/platform_installation.git
-NOTE: consulAgent.sh will be inside ec-deployer-v2.5.1/ec-deployer/bin
-````
-#### 4) Update app-inputs.conf with user defined values
-````
-$ cd ${WORKING-DIR}/dcae-deployer/conf
-$ vi app-inputs.conf
-
- -- Update the following values -
- * CLOUDIFY_INPUT=<complete path to the auto generated inputs.json for cloudify ( downloaded in inputsDirectory from Step 2 )>
- e.g. /home/attcloud/dcae/dcae-deployer/testing/1710-FTL3/cloudify-gen/inputs/bootstrap/bootstrap/rdm5adcc1/inputs.json
- * CONSUL_INPUT=<complete path to the auto generated inputs.json for consul ( downloaded in inputsDirectory from Step 2 )>
- e.g. /home/attcloud/dcae/dcae-deployer/testing/1710-FTL3/cloudify-gen/inputs/consul/consul/rdm5adcc1/inputs.json
- * CONSUL_BLUEPRINT=<complete path to the zip for consul on dockercentral>
- - git clone ssh://git@codecloud.web.att.com:7999/st_ecompcntr/blueprints.git
- e.g. /home/attcloud/blueprints/serviceConfigRegistry/blueprint/consul.yaml
- Note: consul.yaml will be inside blueprints/serviceConfigRegistry/blueprint
- * OPENSTACK_KEYFILE=<complete path the pem file used for bootstraping>
- e.g. '/home/attcloud/dcae-m82823u.pem'
- * OPENSTACK_KEY=<name of the keypair used in openstack>
- e.g. 'dcae-m82823'
- * CLOUDIFY_USERNAME=<Username for Cloudify>
- * CLOUDIFY_PASSWORD=<Password for Cloudify>
- * CONSUL_AGENT=<complete path to the extracted consulAgent.sh from Step 3>
- e.g. /home/attcloud/dcae/dcae-deployer/bin/install/bin/consulAgent.sh
- * LOCATION=<put the value of location_id from consul inputs.json file( downloaded in inputsDirectory from Step 2 )>
-
-Save the file and exit!!
-````
-#### 3) Run the ./deploy.sh script for building entire environment. (This includes, spinning up cloudify manager VM, bootstrapping cloudify manager, and deploying consul blueprint)
-````
-##### Option-1: Just bootstrapping cloudify manager on new VM
- Note: This will instantiate a new VM and will bootstrap it with cloudify 3.4.0
- $ ./deploy.sh --action bootstrap
-````
-````
-##### Option-2: Bootstrap cloudify manager on existing centOS VM
- Note : This will bootstrap the provide IP-ADDRESS with the cloudify 3.4.0
- $ ./deploy.sh --action bootstrap --cloudify-ip <IP-ADDRESS>
-````
-````
-##### Option-3: Teardown cloudify manager
- Note: This will tear down the cloudify from the provided IP-ADDRESS but will not remove the VM
- $ ./deploy.sh --action teardown --cloudify-ip <IP-ADDRESS>
-````
-````
-##### Option-4: Deploy consul
- Note: This will deploy the consul on provided IP-ADDRESS and will instantiate 3 new VMs
- $ ./deploy.sh --action deploy --cloudify-ip <IP-ADDRESS> --component consul
-````
-````
-##### Option-5: Undeploy consul
- Note : This will undeploy the consul from the provide IP-ADDRESS and will remove the 3 VMs
- $ ./deploy.sh --action undeploy --cloudify-ip <IP-ADDRESS> --component consul
-````
\ No newline at end of file diff --git a/platformdoc/Dockerfile b/platformdoc/Dockerfile deleted file mode 100644 index 3a87fa37..00000000 --- a/platformdoc/Dockerfile +++ /dev/null @@ -1,5 +0,0 @@ -FROM nginx:1.11.8 - -# Copies all files into the default directory nginx serves from -# See /etc/nginx/conf.d/default.conf -COPY site /usr/share/nginx/html diff --git a/platformdoc/README.md b/platformdoc/README.md deleted file mode 100644 index 8c4c5996..00000000 --- a/platformdoc/README.md +++ /dev/null @@ -1,54 +0,0 @@ -# dcae-platform-documentation - -Contains the public facing technical documentation for the dcae platform whose audiences include: - -* Architects -* Component developers -* Operations (TBD) - -## Usage - -### Local dev - -This is a [Mkdocs](http://www.mkdocs.org/) project. To serve a local version of the documentation to view your changes: - -1. Install mkdocs and mkdocs-material: - - ``` - pip install mkdocs - pip install mkdocs-material - ``` - -2. Clone this repo - -3. Run the following at the root of the cloned repo: - - ``` - mkdocs serve - ``` -4. View the page at `http://127.0.0.1:8000/` - -### Publish - -1. Generate the site: - - ``` - mkdocs build - ``` - -2. Build the Docker image, tag as desired - eg `dcae-platform-documentation:YYYYMMDD` - - ``` - docker build -t dcae-platform-documentation:20171002 . - ``` - -3. Run the Docker container: - - ``` - export DOCKER_HOST=tcp://<target docker host> - docker stop dpd - docker rm -f dpd - docker run -d --name dpd -p 80:80 dcae-platform-documentation:YYYYMMDD - ``` - -Or email Patty Heffner (ph8547@att.com) diff --git a/platformdoc/docs/architecture/pieces.md b/platformdoc/docs/architecture/pieces.md deleted file mode 100644 index 7787359f..00000000 --- a/platformdoc/docs/architecture/pieces.md +++ /dev/null @@ -1,7 +0,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/platformdoc/docs/architecture/service-discovery.md b/platformdoc/docs/architecture/service-discovery.md deleted file mode 100644 index 9831efcf..00000000 --- a/platformdoc/docs/architecture/service-discovery.md +++ /dev/null @@ -1,15 +0,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/platformdoc/docs/architecture/services.md b/platformdoc/docs/architecture/services.md deleted file mode 100644 index f17f563b..00000000 --- a/platformdoc/docs/architecture/services.md +++ /dev/null @@ -1,11 +0,0 @@ -# 'Services' Overview - -DCAE Services run on the DCAE platform. A service either monitors the virtualized network services or does analytics. A service is composed of one or more components, and performs a business need. - -Services are created in a 'Service Design and Creation' tool called 'Service Assurance Flow Designer' by a Service Designer. This is done by - -* 'compose'ing a service from the available SDC catalog components (actually from the TOSCA models representing the components), then -* 'submit'ing the service, which generates a Cloudify blueprint, which is then automatically uploaded to INVENTORY, and then deployed by DEPLOYMENT HANDLER (and CLOUDIFY) (once a DTI Event is triggered for the service). It should be noted that some service flows, specifally 'closed-loop' flows, are not initiated by DTI, but are done by CLAMP. - -Only a few services are supported in SDC so far, and therefore steps above are done manually by the Onboarding Team for most services. - diff --git a/platformdoc/docs/changelog.md b/platformdoc/docs/changelog.md deleted file mode 100644 index fbd7524a..00000000 --- a/platformdoc/docs/changelog.md +++ /dev/null @@ -1,19 +0,0 @@ -# DCAE Platform Documentation Change Log - -## Versions - -Version | Date Built | ----- | ----- | -Current | 12/20/2017 -Previous | 11/30/2017 - -## Change Log - -Date | Changes | ----- | ----- | -12/20/2017 | updated for DTI, made corrections, add example component spec, added to concept, walkthrough section -11/30/2017 | updated for comments, updated configuration grid, added information about DTI development and configuration, updated Auxilary section, new component_properties section added to component spec, updated component jsonschema for DTI, this creates a new version - v4. (In order to utilize the new schema version, a dcae_cli --reinit needs to be done) -11/14/2017 | added ChangeLog, revised site outline, updated glossary, added dcae_cli commands section detailing each command, added various notes, added specific environment profiles for 1710 and 1802, made major revisions on many pages, added several concepts, added more detailed steps to walk-thru section, added more details about Dmaap Connection Object -10/03/2017 | added configuration grid and examples grid, updated common, cdap and docker specifications, and cdap and docker requirements pages. -09/28/2017 | added streams grid and services page, updated index, overview, and common spec pages - diff --git a/platformdoc/docs/components/component-specification/cdap-specification.md b/platformdoc/docs/components/component-specification/cdap-specification.md deleted file mode 100644 index ce17d811..00000000 --- a/platformdoc/docs/components/component-specification/cdap-specification.md +++ /dev/null @@ -1,127 +0,0 @@ -# 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. - -* [Metadata](common-specification.md#metadata) -* [Interfaces](common-specification.md#interfaces) including the associated [Data Formats](/components/data-formats.md) -* [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. -* [Auxiliary Details](#auxiliary-details) -* [List of artifacts](common-specification.md#artifacts) - - -## Current Limitations and TODOs - -* The integration of DMD is likely to significantly change the [Interfaces](common-specification.md#interfaces) section in this specification.. - -## 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 [Parameter](common-specification.md#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` 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: - -```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/platformdoc/docs/components/component-specification/common-specification.md b/platformdoc/docs/components/component-specification/common-specification.md deleted file mode 100644 index 14c1297c..00000000 --- a/platformdoc/docs/components/component-specification/common-specification.md +++ /dev/null @@ -1,402 +0,0 @@ -# Common Elements of the 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. - -## Meta Schema Definition - -The component specification is represented (and validated) against this -[Component Spec json schema](https://codecloud.web.att.com/projects/ST_DCAECNTR/repos/component-json-schemas/browse/component-spec-schema.json) 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 schema (thus it is a "meta schema"). It requires the name of the component entry, component type (either 'cdap' or 'docker') and a description under "self" object. The meta schema version must be specified as the value of the "version" key. Then the input schema itself is described. - -The table below shows the four types of schema descriptions supported -There are four types of schema descriptions objects - jsonschema for inline standard JSON Schema definitions of JSON inputs, delimitedschema for delimited data input using a JSON description defined by AT&T, unstructured for unstructured text, and reference that allows a pointer to another artifact for a schema. The reference allows for XML schema, but can be used as a pointer to JSON, Delimited Format, and Unstructured schemas as well. - -## Component Metadata -Metadata refers to the properties found under the `self` JSON. This group of properties is used to uniquely identify this component specification and identify the component that this specification is used to capture. - -Example: - -``` -"self": { - "version": "1.0.0", - "name": "asimov.component.kpi_anomaly", - "description": "Classifies VNF KPI data as anomalous", - "component_type": "docker" -}, -``` - -`self` Schema: - -Property Name | Type | Description -------------- | ---- | ----------- -version | string | *Required*. Semantic version for this specification -name | string | *Required*. Full name of this component which is also used as this component's catalog id. -description | string | *Required*. Human-readable text describing the component and the components functional purpose. -component_type | string | *Required*. Identify what containerization technology this component uses: `docker` or `cdap`. - -## Interfaces -Interfaces are the JSON objects found under the `streams` key and the `services` key. These are used to describe the interfaces that the component uses and the interfaces that the component provides. The description of each interface includes the associated [data format](/components/data-formats.md). - -### Streams - * The `streams` JSON is for specifying data produced for consumption by other components, and the streams expected to subscribe to that is produced by other components. These are "fire and forget" type interfaces where the publisher of a stream does not expect or parse a response from the subscriber. -* The term `stream` here is abstract and neither refers to "CDAP streams" or "DMaaP feeds". While a stream is very likely a DMaaP feed, it could be a direct stream of data being routed via HTTP too. It abstractly refers to a sequence of data leaving a publisher. -* Streams have anonymous publish/subscribe semantics, which decouples the production of information from its consumption. -Like the component specification, the data format specification is represented/validated against this -[Data Format json schema](https://codecloud.web.att.com/projects/ST_DCAECNTR/repos/component-json-schemas/browse/data-format-schema.json) - -* In general, components are not aware of who they are communicating with. -* Instead, components that are interested in data, subscribe to the relevant stream; components that generate data publish to the relevant stream. -* There can be multiple publishers and subscribers to a stream. Streams are intended for unidirectional, streaming communication. - - -Streams interfaces that implement an HTTP endpoint must support POST. - -Streams are split into: - -Property Name | Type | Description -------------- | ---- | ----------- -subscribes | JSON list | *Required*. List of all available stream interfaces that this component has that can be used for subscribing -publishes | JSON list | *Required*. List of all stream interfaces that this component will publish onto - -#### Subscribes - -Example: - -```json -"streams": { - "subscribes": [{ - "format": "dcae.vnf.kpi", - "version": "1.0.0", - "route": "/data", // for CDAP this value is not used - "type": "http" - }], -... -} -``` - -This describes that `asimov.component.kpi_anomaly` exposes an HTTP endpoint called `/data` which accepts requests that have the data format of `dcae.vnf.kpi` version `1.0.0`. - -`subscribes` Schema: - -Property Name | Type | Description -------------- | ---- | ----------- -format | string | *Required*. Data format id of the data format that is used by this interface -version | string | *Required*. Data format version of the data format that is used by this interface -route | string | *Required for HTTP and data router*. The HTTP route that this interface listens on -config_key | string | *Required for message_router and data router*. The HTTP route that this interface listens on -type | string | *Required*. Type of stream: `http`, `message_router`, `data_router` - - -##### Message router - -Message router subscribers are http clients rather than http services and performs a http a `GET` call. Thus, message router subscribers description is structured like message router publishers and requires `config_key`: - -```json -"streams": { - "subscribes": [{ - "format": "dcae.some-format", - "version": "1.0.0", - "config_key": "some_format_handle", - "type": "message router" - }], -... -} -``` - -##### Data router - -Data router subscribers are http or https services that handle `PUT` requests from data router. Developers must provide the `route` or url path/endpoint that is expected to handle data router requests. This will be used to construct the delivery url needed to register the subscriber to the provisioned feed. Developers must also provide a `config_key` because there is dynamic configuration information associated with the feed that the application will need e.g. username and password. See the page on [DMaaP connection objects](/components/component-specification/dmaap-connection-objects/#data-router) for more details on the configuration information. - -Example (not tied to the larger example): - -```json -"streams": { - "subscribes": [{ - "config_key": "some-sub-dr", - "format": "sandbox.platform.any", - "route": "/identity", - "type": "data_router", - "version": "0.1.0" - }], -... -} -``` - -#### Publishes - -Example: - -```json -"streams": { -... - "publishes": [{ - "format": "asimov.format.integerClassification", - "version": "1.0.0", - "config_key": "prediction", - "type": "http" - }] -}, - -``` - -This describes that `asimov.component.kpi_anomaly` publishes by making POST requests to streams that support the data format `asimov.format.integerClassification` version `1.0.0`. - -`publishes` Schema: - -Property Name | Type | Description -------------- | ---- | ----------- -format | string | *Required*. Data format id of the data format that is used by this interface -version | string | *Required*. Data format version of the data format that is used by this interface -config_key | string | *Required*. The JSON key in the generated application configuration that will be used to pass the downstream component's (the subscriber's) connection information. -type | string | *Required*. Type of stream: `http`, `message router`, `data router` - -##### Message router - -Message router publishers are http clients of DMaap message_router. Developers must provide a `config_key` because there is dynamic configuration information associated with the feed that the application needs to receive e.g. topic url, username, password. See the page on [DMaaP connection objects](/components/component-specification/dmaap-connection-objects/#message-router) for more details on the configuration information. - -Example (not tied to the larger example): - -```json -"streams": { -... - "publishes": [{ - "config_key": "some-pub-mr", - "format": "sandbox.platform.any", - "type": "message_router", - "version": "0.1.0" - }] -} -``` - -##### Data router - -Data router publishers are http clients that make `PUT` requests to data router. Developers must also provide a `config_key` because there is dynamic configuration information associated with the feed that the application will need to receive e.g. publish url, username, password. See the page on [DMaaP connection objects](/components/component-specification/dmaap-connection-objects/#data-router) for more details on the configuration information. - -Example (not tied to the larger example): - -```json -"streams": { -... - "publishes": [{ - "config_key": "some-pub-dr", - "format": "sandbox.platform.any", - "type": "data_router", - "version": "0.1.0" - }] -} -``` - -#### Quick Reference - -Refer to this [Quick Reference](/components/component-specification/streams-grid.md) for a comparison of the Streams 'Publishes' and 'Subscribes' sections. - - -### Services - -* The publish / subscribe model is a very flexible communication paradigm, but its many-to-many one-way transport is not appropriate for RPC -request / reply interactions, which are often required in a distributed system. -* Request / reply is done via a Service, which is defined by a pair of messages: one for the request and one for the reply. - -Services are split into: - -Property Name | Type | Description -------------- | ---- | ----------- -calls | JSON list | *Required*. List of all service interfaces that this component will call -provides | JSON list | *Required*. List of all service interfaces that this component exposes and provides - -#### Calls -The JSON `services/calls` is for specifying that the component relies on an HTTP(S) service---the component sends that service an HTTP request, and that service responds with an HTTP reply. -An example of this is how string matching (SM) depends on the AAI Broker. SM performs a synchronous REST call to the AAI broker, providing it the VMNAME of the VNF, and the AAI Broker responds with additional details about the VNF. This dependency is expressed via `services/calls`. In contrast, the output of string matching (the alerts it computes) is sent directly to policy as a fire-and-forget interface, so that is an example of a `stream`. - -Example: - -```json -"services": { - "calls": [{ - "config_key": "vnf-db", - "request": { - "format": "dcae.vnf.meta", - "version": "1.0.0" - }, - "response": { - "format": "dcae.vnf.kpi", - "version": "1.0.0" - } - }], -... -} -``` - -This describes that `asimov.component.kpi_anomaly` will make HTTP calls to a downstream component that accepts requests of data format `dcae.vnf.meta` version `1.0.0` and is expecting the response to be `dcae.vnf.kpi` version `1.0.0`. - -`calls` Schema: - -Property Name | Type | Description -------------- | ---- | ----------- -request | JSON object | *Required*. Description of the expected request for this downstream interface -response | JSON object | *Required*. Description of the expected response for this downstream interface -config_key | string | *Required*. The JSON key in the generated application configuration that will be used to pass the downstream component connection information. - -The JSON object schema for both `request` and `response`: - -Property Name | Type | Description -------------- | ---- | ----------- -format | string | *Required*. Data format id of the data format that is used by this interface -version | string | *Required*. Data format version of the data format that is used by this interface - -#### Provides - -Example: - -```json -"services": { -... - "provides": [{ - "route": "/score-vnf", - "request": { - "format": "dcae.vnf.meta", - "version": "1.0.0" - }, - "response": { - "format": "asimov.format.integerClassification", - "version": "1.0.0" - } - }] -}, -``` - -This describes that `asimov.component.kpi_anomaly` provides a service interface and it is exposed on the `/score-vnf` HTTP endpoint. The endpoint accepts requests that have the data format `dcae.vnf.meta` version `1.0.0` and gives back a response of `asimov.format.integerClassification` version `1.0.0`. - -`provides` Schema for a Docker component: - -Property Name | Type | Description -------------- | ---- | ----------- -request | JSON object | *Required*. Description of the expected request for this interface -response | JSON object | *Required*. Description of the expected response for this interface -route | string | *Required*. The HTTP route that this interface listens on - -The JSON object schema for both `request` and `response`: - -Property Name | Type | Description -------------- | ---- | ----------- -format | string | *Required*. Data format id of the data format that is used by this interface -version | string | *Required*. Data format version of the data format that is used by this interface - -Note, for CDAP, there is a slight variation due to the way CDAP exposes services: -``` - "provides":[ // note this is a list of JSON - { - "request":{ ...}, - "response":{ ...}, - "service_name":"name CDAP service", - "service_endpoint":"greet", // E.g the URL is /services/service_name/methods/service_endpoint - "verb":"GET" // GET, PUT, or POST - } - ] -``` - -`provides` Schema for a CDAP component: - -Property Name | Type | Description -------------- | ---- | ----------- -request | JSON object | *Required*. Description of the expected request data format for this interface -response | JSON object | *Required*. Description of the expected response for this interface -service_name | string | *Required*. The CDAP service name (eg "Greeting") -service_endpoint | string | *Required*. The CDAP service endpoint for this service_name (eg "/greet") -verb | string | *Required*. 'GET', 'PUT' or 'POST' - - -## Parameters - -`parameters` is where to specify the component's application configuration parameters that are not connection information. - -Property Name | Type | Description -------------- | ---- | ----------- -parameters | JSON array | Each entry is a parameter object - -Parameter object has the following available properties: - -Property Name | Type | Description | Default -------------- | ---- | ----------- | ------- -name | string | *Required*. The property name that will be used as the key in the generated config | -value | any | *Required*. The default value for the given parameter | -description | string | *Required*. Human-readable text describing the parameter like what its for | -type | string | The required data type for the parameter | -required | boolean | An optional key that declares a parameter as required (true) or not (false) | true -constraints | array | The optional list of sequenced constraint clauses for the parameter. See below | -entry_schema | string | The optional key that is used to declare the name of the Datatype definition for entries of set types such as the TOSCA 'list' or 'map'. Only 1 level is supported at this time | -designer_editable | boolean | An optional key that declares a parameter to be editable by designer (true) or not (false) | -sourced_at_deployment | boolean | An optional key that declares a parameter's value to be assigned at deployment time (true) | -policy_editable | boolean | An optional key that declares a parameter to be editable by policy (true) or not (false) | -policy_schema | array | The optional list of schema definitions used for policy. See below | - -Example: - -```json -"parameters": [ - { - "name": "threshold", - "value": 0.75, - "description": "Probability threshold to exceed to be anomalous" - } -] -``` - -Many of the parameter properties have been copied from TOSCA model property definitions and are to be used for service design composition and policy creation. See [section 3.5.8 *Property definition*](http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.1/TOSCA-Simple-Profile-YAML-v1.1.html). - -The property `constraints` is a list of objects where each constraint object: - -Property Name | Type | Description -------------- | ---- | ----------- -equal | | Constrains a property or parameter to a value equal to (‘=’) the value declared -greater_than | number | Constrains a property or parameter to a value greater than (‘>’) the value declared -greater_or_equal | number | Constrains a property or parameter to a value greater than or equal to (‘>=’) the value declared -less_than | number | Constrains a property or parameter to a value less than (‘<’) the value declared -less_or_equal | number | Constrains a property or parameter to a value less than or equal to (‘<=’) the value declared -valid_values | array | Constrains a property or parameter to a value that is in the list of declared values -length | number | Constrains the property or parameter to a value of a given length -min_length | number | Constrains the property or parameter to a value to a minimum length -max_length | number | Constrains the property or parameter to a value to a maximum length - -`threshold` is the configuration parameter and will get set to 0.75 when the configuration gets generated. - -The property `policy_schema` is a list of objects where each policy_schema object: - -Property Name | Type | Description | Default -------------- | ---- | ----------- | ------- -name | string | *Required*. parameter name -value | string | default value for the parameter -description | string | parameter description -type | enum | *Required*. data type of the parameter, 'string', 'number', 'boolean', 'datetime', 'list', or 'map' -required | boolean | is parameter required or not? | true -constraints | array | The optional list of sequenced constraint clauses for the parameter. See above | -entry_schema | string | The optional key that is used to declare the name of the Datatype definition for certain types. entry_schema must be defined when the type is either list or map. If the type is list and the entry type is a simple type (string, number, bookean, datetime), follow with an string to describe the entry | -| | If the type is list and the entry type is a map, follow with an array to describe the keys for the entry map | -| | If the type is list and the entry type is a list, that is not currently supported -| | If the type is map, follow with an aray to describe the keys for the map | - -## 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 [component dev command](/components/dcae_cli/commands/#run-the-dev-command). - -## Artifacts - -`artifacts` contains a list of artifacts associated with this component. For Docker, this is the full path (including the registry) to the Docker image. For CDAP, this is the full path to the CDAP jar. - -Property Name | Type | Description -------------- | ---- | ----------- -artifacts | JSON array | Each entry is a artifact object - -`artifact` Schema: - -Property Name | Type | Description -------------- | ---- | ----------- -uri | string | *Required*. Uri to the artifact, full path -type | string | *Required*. `docker image` or `jar` - -# Working with Component Specs - -Components can be added to the onboarding catalog (which first validates the component spec) by using the [dcae_cli Tool](http://dcae-platform.research.att.com/components/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 [Component Commands](/components/dcae-cli/commands/#component). - - diff --git a/platformdoc/docs/components/component-specification/configuration-grid.md b/platformdoc/docs/components/component-specification/configuration-grid.md deleted file mode 100644 index e1154218..00000000 --- a/platformdoc/docs/components/component-specification/configuration-grid.md +++ /dev/null @@ -1,19 +0,0 @@ - -# Configuration Quick Reference - -#### Default Values - -The component developer can provide default values for any `parameter` in the component specification. These defaults will be passed to the component in its generated configuration. - -#### 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).* - -||Design-Time Input |CLAMP Input|Policy Input (future) |Deploy-Time Input|Run-Time Input (DTI)| -|-----|-----|-----|-----|----------|----------| -|Description|Applies to SDC self-service components|Applies to components deployed by CLAMP |(not yet supported)|Applies to manually deployed services| Applies to components supporting DTI reconfiguration| -|Input provided by|Service Designer|CLAMP|Operations|DevOps|Runtime Platform(DTI)| -|How it is provided |In the SDC UI |In the CLAMP UI |In the POLICY GUI |In the DCAE Dashboard (or Jenkins job)|In the DTI Event -|Component Specification Details|‘designer-editable’ set to ‘true’| None. Developer provides CLAMP an email with parameters to be supported|‘policy_editable’ must be set to ‘true’ and ‘policy_schema’ must be provided|'sourced_at_<br>deployment' must be set to 'true'|parameter 'dcae_target_type' defined with default value set to supported vnfType-vnfFuncId, with properties 'designer_editable' and 'sourced_at_deployment' set appropriately| -|Additional Info for Component Developer|||For Docker only: In the auxiliary section:<br> {"policy": {"trigger_type": "policy","script_path": “/opt/app/reconfigure.sh”} }<br> Script interface would then be "/opt/app/reconfigure.sh” $trigger_type $updated_policy" <br> where $updated_policy is json provided by the Policy Handler.||For Docker only: In the auxiliary section:<br> {"dti": “/opt/app/reconfigure.sh”} <br> Script interface would then be "/opt/app/reconfigure.sh” $trigger_type $updated_dti" <br> where $updated_dti is json provided by the DTI Plugin.| diff --git a/platformdoc/docs/components/component-specification/dmaap-connection-objects.md b/platformdoc/docs/components/component-specification/dmaap-connection-objects.md deleted file mode 100644 index b1b650fd..00000000 --- a/platformdoc/docs/components/component-specification/dmaap-connection-objects.md +++ /dev/null @@ -1,169 +0,0 @@ -# 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*". - -## Message Router - -Publishers and subscribers have the same generated `Dmaap Connection Object` structure. Here's an example for any given config-key: -(This is what will be in application_configuration) - -```json -{ - "type": "message_router", - "aaf_username": "some-user", - "aaf_password": "some-password", - "dmaap_info": { - "client_role": "com.dcae.member", - "client_id": "1500462518108", - "location": "mtc00", - "topic_url": "https://we-are-message-router.us:3905/events/some-topic" - } -} -``` - -At the top-level: - -Property Name | Type | Description -------------- | ---- | ----------- -type | string | *Required as input*. Must be `message_router` for message router topics -aaf_username | string | AAF username message router clients use to authenticate with secure topics -aaf_password | string | AAF password message router clients use to authenticate with secure topics -dmaap_info | JSON object | *Required as input*. Contains the topic connection details - -The `dmaap_info` object contains: - -Property Name | Type | Description -------------- | ---- | ----------- -client_role | string | AAF client role that's requesting publish or subscribe access to the topic -client_id | string | Client id for given AAF client -location | string | DCAE location for the publisher or subscriber, used to set up routing -topic_url | string | *Required as input*. URL for accessing the topic to publish or receive events - -The --dmaap-file argument (to the component `run` or `dev` command), must minimally contain: - -```json -{ - "type": "message_router", - "dmaap_info": { - "topic_url": "https://we-are-message-router.us:3905/events/some-topic" - } -} -``` - -## Data Router - -### Publisher - -Here's an example of what the generated `Dmaap Connection Object` for Data Router Publisher looks like: -(This is what will be in application_configuration) - -```json -{ - "type": "data_router", - "dmaap_info": { - "location": "mtc00", - "publish_url": "https://we-are-data-router.us/feed/xyz", - "log_url": "https://we-are-data-router.us/feed/xyz/logs", - "username": "some-user", - "password": "some-password", - "publisher_id": "123456" - } -} -``` - -At the top-level: - -Property Name | Type | Description -------------- | ---- | ----------- -type | string | *Required as input*. Must be `data_router` for data router feeds -dmaap_info | JSON object | *Required as input*. Contains the feed connection details - -The `dmaap_info` object contains: - -Property Name | Type | Description -------------- | ---- | ----------- -location | string | DCAE location for the publisher, used to set up routing -publish_url | string | *Required as input*. URL to which the publisher makes Data Router publish requests -log_url | string | URL from which log data for the feed can be obtained -username | string | Username the publisher uses to authenticate to Data Router -password | string | Password the publisher uses to authenticate to Data Router -publisher_id | string | Publisher id in Data Router - -The --dmaap-file argument (to the component `run` or `dev` command), must minimally contain: - -```json -{ - "type": "data_router", - "dmaap_info": { - "publish_url": "https://we-are-data-router.us/feed/xyz" - } -} -``` - -### Subscriber - -Here's an example of what the generated `Dmaap Connection Object` for a Data Router Subscriber looks like: -(This is what will be passed in application_configuration) - -```json -{ - "type": "data_router", - "dmaap_info": { - "location": "mtc00", - "delivery_url": "https://my-subscriber-app.dcae:8080/target-path", - "username": "some-user", - "password": "some-password", - "subscriber_id": "789012" - } -} -``` - -At the top-level: - -Property Name | Type | Description -------------- | ---- | ----------- -type | string | *Required as input*. Must be `data_router` for data router feeds -dmaap_info | JSON object | *Required as input*. Contains the feed connection details - -The `dmaap_info` object contains: - -Property Name | Type | Description -------------- | ---- | ----------- -location | string | DCAE location for the subscriber, used to set up routing -delivery_url | string | URL to which the Data Router should deliver files -username | string | Username Data Router uses to authenticate to the subscriber when delivering files -password | string | Password Data Router uses to authenticate to the subscriber when delivering files -subscriber_id | string | Subscriber id in Data Router - -The --dmaap-file argument (to the component `run` or `dev` command), must minimally contain: - -```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/platformdoc/docs/components/component-specification/docker-specification.md b/platformdoc/docs/components/component-specification/docker-specification.md deleted file mode 100644 index 60905046..00000000 --- a/platformdoc/docs/components/component-specification/docker-specification.md +++ /dev/null @@ -1,273 +0,0 @@ -# Component specification (Docker) - -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. - -* [Metadata](common-specification.md#metadata) -* [Interfaces](common-specification.md#interfaces) including the associated [Data Formats](/components/data-formats.md) -* [Parameters](common-specification.md#parameters) -* [Auxiliary Details](#auxiliary-details) -* [List of Artifacts](common-specification.md#artifacts) - -## Auxiliary Details - -`auxiliary` contains Docker specific details like health check, port mapping, volume mapping, dti and policy reconfiguration script details. (Policy reconfiguration is not yet supported). - -Name | Type | Description -------------- | ---- | ----------- -healthcheck | JSON object | *Required*. Health check definition details -ports | JSON array | each array item maps a container port to the host port. See example below. -volume | JSON array | each array item contains a host and container object. See example below. -reconfigs | string | DTI reconfiguration script details -*Planned for 1806* | | -policy | JSON array | *Required*. 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. - -When choosing a value for interval, consider that too frequent healthchecks will put unnecessary load on Consul and DCAE. If there is a problematic resource, then more frequent healthchecks are warranted (eg 15s or 60s), but as stablility increases, so can these values, (eg 300s). - -When choosing a value for timeout, consider that too small a number will result in increasing timeout failures, and too large a number will result in a delay in the notification of the resource problem. A suggestion is to start with 5s and work from there. - -#### http - -Property Name | Type | Description -------------- | ---- | ----------- -type | string | *Required*. `http` -interval | string | Interval duration in seconds i.e. `60s` -timeout | string | Timeout in seconds i.e. `5s` -endpoint | string | *Required*. GET endpoint provided by the component for Consul to call to check health - -Example: - -```json -"auxilary": { - "healthcheck": { - "type": "http", - "interval": "15s", - "timeout": "1s", - "endpoint": "/my-health" - } -} -``` - -#### docker script example - -Property Name | Type | Description -------------- | ---- | ----------- -type | string | *Required*. `docker` -interval | string | Interval duration in seconds i.e. `15s` -timeout | string | Timeout in seconds i.e. `1s` -script | string | *Required*. Full path of script that exists in the Docker container to be 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 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. - -Example: - -```json -"auxilary": { - "healthcheck": { - "type": "docker", - "script": "/app/resources/check_health.py", - "timeout": "30s", - "interval": "180s" - } -} -``` - -### Ports - -This method of exposing/mapping a local port to a host port is NOT RECOMMENDED because of the possibility of port conflicts. If multiple instances of a docker container will be running, there definitely will be port conflicts. Use at your own risk. (The preferred way to expose a port is to do so in the Dockerfile as described [here](/components/component-type-docker/#ports)). - -```json -"auxilary": { - "ports": ["8080:8000"] -} -``` - -In the example above, container port 8080 maps to host port 8000. - -### Volume Mapping - -```json -"auxilary": { - "volumes": [ - { - "container": { - "bind": "/tmp/docker.sock", - "mode": "ro" - }, - "host": { - "path": "/var/run/docker.sock" - } - } - ] -} -``` - -At the top-level: - -Property Name | Type | Description -------------- | ---- | ----------- -volumes | array | Contains container and host objects - -The `container` object contains: - -Property Name | Type | Description -------------- | ---- | ----------- -bind | string | path to the container volume -mode | string | "ro" - indicates read-only volume - | | "" - indicates that the contain can write into the bind mount - -The `host` object contains: - -Property Name | Type | Description -------------- | ---- | ----------- -path | string | path to the host volume - -Here's an example of the minimal JSON that must be provided as an input: - -```json -"auxilary": { - "volumes": [ - { - "container": { - "bind": "/tmp/docker.sock" - }, - "host": { - "path": "/var/run/docker.sock" - } - } - ] -} -``` - -In the example above, the container volume "/tmp/docker.sock" maps to host volume "/var/run/docker.sock". - -### DTI Reconfiguration - -DTI changes will be provided to the Docker component by triggering a script that is defined here. - -Property Name | Type | Description -------------- | ---- | ----------- -dti | string | *Required*. Suggested value is "/opt/app/reconfigure.sh" - -Example: - -```json -"auxilary": { - "dti": "/opt/app/reconfigure.sh" -} -``` - -The docker script interface is as follows: <br><br> `/opt/app/reconfigure.sh $reconfigure_type {<updated_dti object>} - -Name | Type | Description ----- | ---- | ----------- -reconfigure_type | string | "dti" -updated_dti | json | dti_event object - -The dti_event object can be seen [here](https://codecloud.web.att.com/projects/ST_DCAE/repos/com.att.dcae.orch.dti-handler/browse/dti_inputs.yaml). - -An example of a DTI reconfiguration script can be found [here](https://codecloud.web.att.com/projects/ST_DCAECNTR/repos/docker-cloudify/browse/examples/reconfigure.py?at=refs%2Fheads%2Frelease%2F1802). - - -### Policy (not yet supported) - -Policy changes made in the Policy UI will be provided to the Docker component by triggering a script that is defined here. - -Property Name | Type | Description -------------- | ---- | ----------- -reconfigure_type | string | *Required*. Current value supported is `policy` -script_path | string | *Required*. Current value for 'policy' reconfigure_type must be "/opt/app/reconfigure.sh" - -Example: - -```json -"auxilary": { - "policy": { - "reconfigure_type": "policy", - "script_path": "/opt/app/reconfigure.sh" - } -} -``` - -The docker script interface is as follows: <br><br> `/opt/app/reconfigure.sh $reconfigure_type {"updated policies": <updated policies object>, "application config": <applcation config object>} - -Name | Type | Description ----- | ---- | ----------- -reconfigure_type | string | "policy" -updated_policies | json | TBD -updated_appl_config | json | complete generated app_config, not fully-resolved, but `policy-enabled` parameters have been updated. In order to get the complete updated app_config, the component would have to call `config-binding-service`. - - -## Docker Component Spec - Complete Example - -```json -{ - "self": { - "version": "1.0.0", - "name": "asimov.component.kpi_anomaly", - "description": "Classifies VNF KPI data as anomalous", - "component_type": "docker" - }, - "streams": { - "subscribes": [{ - "format": "dcae.vnf.kpi", - "version": "1.0.0", - "route": "/data", - "type": "http" - }], - "publishes": [{ - "format": "asimov.format.integerClassification", - "version": "1.0.0", - "config_key": "prediction", - "type": "http" - }] - }, - "services": { - "calls": [{ - "config_key": "vnf-db", - "request": { - "format": "dcae.vnf.meta", - "version": "1.0.0" - }, - "response": { - "format": "dcae.vnf.kpi", - "version": "1.0.0" - } - }], - "provides": [{ - "route": "/score-vnf", - "request": { - "format": "dcae.vnf.meta", - "version": "1.0.0" - }, - "response": { - "format": "asimov.format.integerClassification", - "version": "1.0.0" - } - }] - }, - "parameters": [ - { - "name": "threshold", - "value": 0.75, - "description": "Probability threshold to exceed to be anomalous" - } - ], - "auxilary": { - "healthcheck": { - "type": "http", - "interval": "15s", - "timeout": "1s", - "endpoint": "/my-health" - } - }, - "artifacts": [{ - "uri": "fake.nexus.att.com/dcae/kpi_anomaly:1.0.0", - "type": "docker image" - }] -} -``` - diff --git a/platformdoc/docs/components/component-specification/examples-grid.md b/platformdoc/docs/components/component-specification/examples-grid.md deleted file mode 100644 index 9597e537..00000000 --- a/platformdoc/docs/components/component-specification/examples-grid.md +++ /dev/null @@ -1,18 +0,0 @@ -# Component Spec Examples - -The following table shows CDAP and Docker component spec examples for some of the commonly used platform features. Please note that these examples were chosen for the specific features that they contain, and should not necessarily be used for examples of other features, as they may have been captured before they were complete or modified to best utilize those features. - -| Feature | CDAP Example | Docker Example | -|---------|--------------|----------------| -| Dmaap MR subscriber | [String Matching](https://codecloud.web.att.com/projects/ST_DCAECNTR/repos/dcae_cli_examples/browse/sm/sm_spec.json) | TBD | -| Dmaap MR publisher | [String Matching](https://codecloud.web.att.com/projects/ST_DCAECNTR/repos/dcae_cli_examples/browse/sm/sm_spec.json) | [Syslog spec](https://codecloud.web.att.com/projects/ST_DCAECNTR/repos/dcae_cli_examples/browse/syslog/syslog.json) | -| Dmaap DR subscriber/DMD | TBD | [Sessionization](https://codecloud.web.att.com/projects/ST_DCAECNTR/repos/dcae_cli_examples/browse/sessionization/sessionization-componentspec.json) | -| Dmaap DR publisher/DMD | TBD | [Sessionization](https://codecloud.web.att.com/projects/ST_DCAECNTR/repos/dcae_cli_examples/browse/sessionization/sessionization-componentspec.json) | -| Policy (simple) | [tca_policy2](https://codecloud.web.att.com/projects/ST_DCAECNTR/repos/dcae_cli_examples/browse/tca_with_policy2/tca_with_policy2.json) | TBD | -| Policy (complex) | [tca_policy](https://codecloud.web.att.com/projects/ST_DCAECNTR/repos/dcae_cli_examples/browse/tca_with_policy/tca_with_policy.json) | TBD | -| Healthcheck | N/A (the platform does this) | [FOI spec](https://codecloud.web.att.com/projects/ST_DCAECNTR/repos/dcae_cli_examples/browse/foi/foisftpcollector_componentspec.json) -| Service Calls | [String Matching](https://codecloud.web.att.com/projects/ST_DCAECNTR/repos/dcae_cli_examples/browse/sm/sm_spec.json) | TBD | -| Service Provides | [cuda](https://codecloud.web.att.com/projects/ST_DCAECNTR/repos/dcae_cli_examples/browse/cuda/spec.json) | [VES](https://codecloud.web.att.com/projects/ST_DCAECNTR/repos/dcae_cli_examples/browse/ves/vescollector-componentspec.json) | -| DTI Reconfig | TBD | [FOI-sftp](https://codecloud.web.att.com/projects/ST_DCAECNTR/repos/dcae_cli_examples/browse/foi-sftp/component_spec.json) | - - diff --git a/platformdoc/docs/components/component-specification/streams-grid.md b/platformdoc/docs/components/component-specification/streams-grid.md deleted file mode 100644 index b6d64745..00000000 --- a/platformdoc/docs/components/component-specification/streams-grid.md +++ /dev/null @@ -1,60 +0,0 @@ - -# Streams Formatting Quick Reference - -Each of the following tables represents an example of a publisher and its subscriber, which are of course, different components. This focuses on the fields that are ‘different’ for each of these TYPEs, to illustrate the relationship between `config_key`, dmaap connection object, and the generated configuration. Some notes on specific properties: - -* `config_key` is an arbitrary string, chosen by the component developer. It is returned in the generated configuration where it contains specific values for the target connection -* `format`, `version`, and `type` properties in the subscriber would match these properties in the publisher -* `aaf_username` and `aaf_password` may be different between the publisher and the subscriber - - - -### Using http - -#### *Publishing Component* - -| component spec | runtime platform generated config | -|----------------|-----------------------------------| -|"streams":{<br> "publishes":[{<br> "config_key":"prediction",<br> "format":"some-format",<br> "type":"http",<br> "version":"0.1.0"<br> }]<br>}<br>|"streams_publishes":{<br> "prediction":["10.100.1.100:32567/data"] | - -#### *Subscribing Component* - -| component spec | runtime platform generated config | -|----------------|-----------------------------------| -|"streams":{<br> "subscribes":[{<br> "route":"/data",<br> "format":"some-format",<br> "type":"http",<br> "version":"0.1.0"<br> }]<br>}<br>|"N/A"| - - - -### Using Message Router - -#### *Publishing Component* - -Note: When deploying, this component should be deployed first so satisfy downstream dependencies. Refer to the –force option in component ‘run’ command for more information. - -| component spec | Dmaap Connection Object | runtime platform generated config | -|----------------|-------------------------| --------------------------------- | -|"streams":{<br> "publishes":[{<br> "config_key":"mr_output",<br> "format":"some-format",<br> "type":"message_router",<br> "version":"0.1.0"<br> }]<br>} | {<br> "type":"message_router",<br> "dmaap_info": {<br> "topic_url": "https://we-are-message-router.us:3905/events/some-topic" }<br>} <br><br>*Note: For message router, this object is identical for the publisher and the subscriber* | "streams_publishes":{<br> "mr_output":{<br> "aaf_username":"pub-user",<br> "aaf_password":"pub-pwd",<br> "type":"message_router",<br> "dmaap_info":{<br> "topic_url":"https://we-are-message-router.us:3905/events/some-topic"}<br> }<br>},<br> "streams_subscribes":{<br>…<br>} - -#### *Subscribing Component* - -| component spec | Dmaap Connection Object | runtime platform generated config | -|----------------|-------------------------| --------------------------------- | -|"streams":{<br> "subscribes":[{<br> "config_key":"mr_input",<br> "format":"some-format",<br> "type":"message_router",<br> "version":"0.1.0"<br> }]<br>} | {<br> "type":"message_router",<br> "dmaap_info": {<br> "topic_url": "https://we-are-message-router.us:3905/events/some-topic" }<br>} <br><br>*Note: For message router, this object is identical for the publisher and the subscriber* | "streams_publishes":{<br>…<br>},<br> "streams_subscribes":{<br> "mr_input":{<br> "aaf_username":"sub-user",<br> "aaf_password":"sub-pwd",<br> "type":"message_router",<br> "dmaap_info":{<br> "topic_url":"https://we-are-message-router.us:3905/events/some-topic"}<br> }<br>} - - - - -### Using Data Router - -#### *Publishing Component* - -| component spec | Dmaap Connection Object | runtime platform generated config | -|----------------|-------------------------| --------------------------------- | -|"streams":{<br> "publishes":[{<br> "config_key":"dr_output",<br> "format":"some-format",<br> "type":"data_router",<br> "version":"0.1.0"<br> }]<br>} | {<br> "type":"data_router",<br> "dmaap_info": {<br> "location": "mtc00",<br> "publish_url": "https://we-are-data-router.us/feed/xyz", <br> "log_url": "https://we-are-data-router.us/feed/xyz/logs",<br> "username": "pub-user",<br> "password": "pub-password",<br> "publisher_id": "123456"}<br>} | streams_publishes":{<br> "dr_output":{<br> "type":"data_router",<br> "dmaap_info":{<br> "location":"mtc00",<br> "publish_url":"https://we-are-data-router.us/feed/xyz",<br> "log_url":"https://we-are-data-router.us/feed/xyz/logs",<br> "username":"pub-user",<br> "password":"pub-password",<br> "publisher_id":"123456"}<br> }<br>},<br> "streams_subscribes":{<br> …<br> } - -#### *Subscribing Component* - -| component spec | Dmaap Connection Object | runtime platform generated config | -|----------------|-------------------------| --------------------------------- | -|"streams":{<br> "subscribes":[{<br> "config_key":"dr_input",<br> "format":"some-format",<br> "type":"data_router",<br> "version":"0.1.0",<br> "route":"/target-path"<br> }]<br>} | {<br> "type":"data_router",<br> "dmaap_info": {<br> "location": "mtc00",<br> "delivery_url": "https://my-subscriber-app.dcae:8080/target-path", <br> "username": "sub-user",<br> "password": "sub-password",<br> "subscriber_id": "789012"}<br>} | "streams_publishes":{<br> …<br> },<br> "streams_subscribes":{<br> "dr_input":{<br> "type":"data_router",<br> "dmaap_info":{<br> "location":"mtc00",<br> "delivery_url":"https://my-subscriber-app.dcae:8080/target-path",<br> "username":"sub-user",<br> "password":"sub-password",<br> "subscriber_id":"789012"}<br> }<br>} - diff --git a/platformdoc/docs/components/component-type-cdap.md b/platformdoc/docs/components/component-type-cdap.md deleted file mode 100644 index 8658b2da..00000000 --- a/platformdoc/docs/components/component-type-cdap.md +++ /dev/null @@ -1,52 +0,0 @@ -# CDAP Component Requirements/Information - -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 'dcae-dev:dev123' http://nexus01.research.att.com:8081/repository/dcae-dev-raw/jar_files/NAME.jar --upload-file NAME.jar -``` -During the CLI Tool Usage, in your spec, supply `http://nexus01.research.att.com:8081/repository/dcae-dev-raw/jar_files/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}}). - -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. - -## Future DMaaP abstraction -Shown below is our _vision_ for how DMaaP is abstracted from component developers: - - - -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: - - - diff --git a/platformdoc/docs/components/component-type-docker.md b/platformdoc/docs/components/component-type-docker.md deleted file mode 100644 index 6e717a5e..00000000 --- a/platformdoc/docs/components/component-type-docker.md +++ /dev/null @@ -1,388 +0,0 @@ -# Component Requirements: Docker - -## Overview - -Component developers are required to provide artifacts for the platform to be able to deploy your component including: - -* [Component Specification](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](#configuration-management) -* [Docker on the Platform](#docker-on-the-platform) -* [Operational Concerns](#operational-concerns) - -Additional considerations are: - -* [DTI Reconfiguration](#dti-reconfiguration) -* [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 [`dcae-cli`](dcae-cli/quickstart) is provided by the platform team. (Testing withing the dcae_cli tool is not yet available for DTI Reconfiguration or Policy). - -## Service Registration - -Every [Docker component is registered](../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 [Docker auxiliary specification](component-specification/docker-specification#auxiliary). - -## 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 or :dti. 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, DTI Reconfiguration, or Pollicy Reconfiguration (not yet supported). - -You can see more details on the generated application configuration [here](/components/dcae-cli/walkthrough/#view-the-platform-generated-configuration) - -### 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 (such as :dti) 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 [dcae-cli `dev` command](/components/dcae-cli/walkthrough/#view-the-platform-generated-configuration) 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://dcae-msrt-mtl5-ftl2.homer.att.com: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://dcae-msrt-ftl2.homer.att.com: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. - -### DTI Reconfiguration - -Most Collector components will support DTI reconfiguration. That is, they must be designed to process multiple instances of a particular `vnfType-vnfFuncId`. When instances of that vnfType-vnfFuncId` are brought up or down, the collectors `reconfiguration script` will be executed. The components reconfiguration script must be defined with the following interfact: - -``` -`/opt/app/reconfigure.sh” dti $updated_dti` -``` -where $updated_dti is a json for one vnfType-vnfFuncId instance that looks like this (for example). -Note: The reconfigure script does not have to be named 'reconfigure.sh'. - -For a deployment of VNF Instance -``` -{ - "deploy": { - "vhss-ems": { - "zrdm3avhss01ems001": { - "dcae_target_collection_ip": "107.239.223.191", - ...the remaining dti_input parameters... - } - } - } -} -``` -For an undeployment of VNF instance -``` -{ - "undeploy": { - "vhss-ems": [ - "zrdm3avhss01ems002" - ] - } -} -``` - -The component spec must contain the following: - -* In the auxilary section, add the definition for the above reconfiguration script for the 'reconfigs' property. This is the script that the platform will call with DTI input when a DTI event is received for the collector supporting the specific dcae_target_type. -* In the parameter section, define a parameter 'dcae_target_type' defined with properties 'designer_editable' and property 'sourced_at_deployment'. Set 'designer_editable' to true if this is an SDC Self-Service microservice. Otherwise, set it to false. Set 'sourced_at_deployment' to true if input can be provided at deployment time by Operations. Otherwise set it to false. - -The component spec can retrieve information about ALL the instances it supports by doing a curl command to CONFIG BINDING SERVICE like this: - -``` -curl http://<config binding service>:<port>/dti/$SERVICE_NAME -``` - -This would return the following: -``` -{ - "vhss-ems": { - "zrdm3avhss01ems001": { - "dcae_target_collection_ip": "107.239.223.191", - the rest of the DTI_input fields… - }, - "zrdm3avhss01ems002": { - "dcae_target_collection_ip": "107.239.223.192", - the rest of the DTI_input fields… - } - } -} -``` -The full list of DTI parameters can be found [here](https://codecloud.web.att.com/projects/ST_DCAE/repos/com.att.dcae.orch.dti-handler/browse/dti_inputs.yaml). - -(The API for the CONFIG BINDING SERVICE is): -``` - /dti/{service_component_name} - parameters: - name: "service_component_name" - in: "path" - description: "Service Component Name. service_component_name:dti must be a key in consul." (see -below for example output) - required: true - type: "string" - get: - description: "Returns as JSON the value for service_component_name:dti" - operationId: "config_binding_service.controller.dti" - responses: - 200: - description: OK; the KV value is returned as an object - schema: - type: object - 404: - description: there is no configuration in Consul for this component's DTI events -``` - -### 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 [message router](component-specification/common-specification/#message-router) topic or to a [data router](component-specification/common-specification/#data-router) feed. Given a composition with components that use DMaaP, the platform will provision the topic or feed and provide the necessary [connection details](/components/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 [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://dcae-drps-ftl2.homer.att.com/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 [Docker auxiliary specification](component-specification/docker-specification#policy-example)) 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 laika has been tagged for an example Nexus registry: - -``` -$ docker images -REPOSITORY TAG IMAGE ID CREATED SIZE -nexus01.research.att.com:18443/dcae-platform/laika 0.4.0 154cc382df61 7 weeks ago 710.5 MB -laika 0.4.0 154cc382df61 7 weeks ago 710.5 MB -``` - -The solutioning evironment's Nexus host for the Docker registry is `nexus01.research.att.com:18443`. You must run `docker login nexus01.research.att.com:18443` to access the registry. Please contact the DCAE platform team to provide you with the credentials. - -``` -docker login nexus01.research.att.com:18443 -``` - -Tag your image: - -``` -docker tag laika:0.4.0 nexus01.research.att.com:18443/dcae-platform/laika:0.4.0 -``` - -Or build and tag: - -``` -docker build -t nexus01.research.att.com:18443/dcae-platform/laika: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 nexus01.research.att.com:18443/dcae-platform/laika:0.4.0 -``` - -*NOTE* Replace `dcae-platform` with the group directory that is applicable to your image. Replace `laika` 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) - -### 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": "realsolcnsl00.dcae.solutioning.homer.att.com", - "docker_host": "realsolcpdokr00.dcae.solutioning.homer.att.com:2376" -} -``` - -* Set your Docker client to point to the target Docker host: - -``` -$ export DOCKER_HOST="tcp://realsolcpdokr00.dcae.solutioning.homer.att.com:2376" -``` - -* Use the `docker logs` command: - -``` -$ docker logs <generated component name> -``` diff --git a/platformdoc/docs/components/data-formats.md b/platformdoc/docs/components/data-formats.md deleted file mode 100644 index 9dd0a65f..00000000 --- a/platformdoc/docs/components/data-formats.md +++ /dev/null @@ -1,74 +0,0 @@ -# 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 components that have compatible data formats. Data formats will be onboarded to SDC 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 Z). - -Since data formats will be shared across components, the onboarding catalog should be checked first to see if the desired data format is available before creating one. -The vision is to have a repository of shared data formats that developers and teams can re-use and also provide them the means to extend and create new custom data formats. -A data format is referenced by its data format id and version number. - -## JSON schema - -The data format specification is represented (and validated) against this -[Data Format json schema](https://codecloud.web.att.com/projects/ST_DCAECNTR/repos/component-json-schemas/browse/data-format-schema.json) and described below: - -### Meta Schema Definition - -The "Meta Schema" implementation defines how data format JSON schemas can be written to define user input. It is itself a JSON schema (thus it is a "meta schema"). It requires the name of the data format entry, the data format entry version and allows a description under "self" object. The meta schema version must be specified as the value of the "dataformatversion" key. Then the input schema itself is described as one of the four types listed below: - -Type | Description ----- | ----------- -jsonschema | inline standard JSON Schema definitions of JSON inputs -delimitedschema | delimited data input using a JSON description and defined delimiter -unstructured | unstructured text, and reference that allows a pointer to another artifact for a schema. -reference | allows for XML schema, but can be used to reference other JSON, delimitedschema, and unstructured schemas as well. - -## Example Schemas: - -### `jsonschema` - -* [TCA output](https://codecloud.web.att.com/projects/ST_DCAECNTR/repos/dcae_cli_examples/browse/tca_hi_lo/tcaoutput.json) - -* [CUDA simple example](https://codecloud.web.att.com/projects/ST_DCAECNTR/repos/dcae_cli_examples/browse/cuda/simplejson.json) - -* [CUDA nested example](https://codecloud.web.att.com/projects/ST_DCAECNTR/repos/dcae_cli_examples/browse/cuda/nestedjson.json) - -### `delimitedschema` - -``` -{ - "self": { - "name": "Delimited Format Example", - "version": "1.0.0", - "description": "Delimited format example just for testing" - - }, - "dataformatversion": "1.0.0", - "delimitedschema": { - "delimiter": "|", - "fields": [{ - "name": "field1", - "description": "test field1", - "fieldtype": "string" - }, { - "name": "field2", - "description": "test field2", - "fieldtype": "boolean" - }] - } -} -``` - -### `unstructured` - -* [CUDA example](https://codecloud.web.att.com/projects/ST_DCAECNTR/repos/dcae_cli_examples/browse/cuda/unstructuredtext.json) - -### `reference` - -* [TCA Hi Lo input](https://codecloud.web.att.com/projects/ST_DCAECNTR/repos/dcae_cli_examples/browse/tca_hi_lo/tcainput.json) - -Note: The referenced data format (in this case, a schema named "Common Event Format" with version of "25.0.0") must already exist in the onboarding catalog. - -## Working with Data Formats - -Data Formats can be added to the onboarding catalog (which first validates them) by using the [dcae_cli Tool](http://dcae-platform.research.att.com/components/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 [Data Format Commands](/components/dcae-cli/commands/#data_format). - diff --git a/platformdoc/docs/components/dcae-cli/blueprint-generator/blueprint_generator.rst b/platformdoc/docs/components/dcae-cli/blueprint-generator/blueprint_generator.rst deleted file mode 100644 index d55804f0..00000000 --- a/platformdoc/docs/components/dcae-cli/blueprint-generator/blueprint_generator.rst +++ /dev/null @@ -1,78 +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/cli/blueprint-generator/1.2.1/blueprint-generator-1.2.1-executable.jar>`_ or running - ``wget https://nexus.onap.org/service/local/repositories/releases/content/org/onap/dcaegen2/platform/cli/blueprint-generator/1.2.1/blueprint-generator-1.2.1-executable.jar`` - -2. To execute the application, run the following command: - ``java -jar blueprint-generator-1.2.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.2.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.2.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 diff --git a/platformdoc/docs/components/dcae-cli/commands.md b/platformdoc/docs/components/dcae-cli/commands.md deleted file mode 100644 index d198f947..00000000 --- a/platformdoc/docs/components/dcae-cli/commands.md +++ /dev/null @@ -1,453 +0,0 @@ -# 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 | -+--------------------------------+---------+--------+---------------------------------------------------------------------+--------+-----------+------------+ -| AAI_Broker | 3.1.0 | docker | DCAE Interface to DTI's AAI View | tc677g | published | 2017-06-15 | -| 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 | | | | -| TCA Alert Definition | 1.0.0 | The format of the output event from TCA | 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" - }, - -... - -``` - ---------------------------------------------------------------------------- - -## `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. -``` - ---------------------------------------------------------------------------- - -### 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.laika | 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 deploymed components - ---------------------------------------------------------------------------- - -### 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 [Dmaap Connection Object](/components/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.laika:0.5.0 - -DCAE.Docker | INFO | Running image 'registry.proto.research.att.com/dcae-rework/laika:0.4.0' as 'mh677g.b7287639-37f5-4f25-8d54-8a2087f4c8da.0-5-0.sandbox-platform-laika' -DCAE.Docker.mh677g.b7287639-37f5-4f25-8d54-8a2087f4c8da.0-5-0.sandbox-platform-laika | INFO | Consul host: realsolcnsl00.dcae.solutioning.homer.att.com - -DCAE.Docker.mh677g.b7287639-37f5-4f25-8d54-8a2087f4c8da.0-5-0.sandbox-platform-laika | INFO | service name: mh677g.b7287639-37f5-4f25-8d54-8a2087f4c8da.0-5-0.sandbox-platform-laika - -DCAE.Docker.mh677g.b7287639-37f5-4f25-8d54-8a2087f4c8da.0-5-0.sandbox-platform-laika | INFO | Generated config: {'multiplier': 3} - -DCAE.Docker.mh677g.b7287639-37f5-4f25-8d54-8a2087f4c8da.0-5-0.sandbox-platform-laika | INFO | * Running on http://0.0.0.0:8080/ (Press CTRL+C to quit) - -DCAE.Docker.mh677g.b7287639-37f5-4f25-8d54-8a2087f4c8da.0-5-0.sandbox-platform-laika | INFO | 135.205.226.140 - - [24/May/2017 03:37:57] "GET /health HTTP/1.1" 200 - - -DCAE.Docker.mh677g.b7287639-37f5-4f25-8d54-8a2087f4c8da.0-5-0.sandbox-platform-laika | INFO | 135.205.226.140 - - [24/May/2017 03:38:12] "GET /health HTTP/1.1" 200 - -``` - -Hit Ctrl-C to terminate session. - -``` -^CDCAE.Docker | INFO | Stopping container 'mh677g.b7287639-37f5-4f25-8d54-8a2087f4c8da.0-5-0.sandbox-platform-laika' and cleaning up... -``` - -#### Run a component in unattached mode: - -``` -$ dcae_cli -v component run sandbox.platform.laika:0.5.0 -DCAE.Docker | INFO | Running image 'registry.proto.research.att.com/dcae-rework/laika:0.4.0' as 'mh677g.4811da0e-08d5-429f-93bf-bf6814924577.0-5-0.sandbox-platform-laika' -DCAE.Run | INFO | Deployed /mh677g.4811da0e-08d5-429f-93bf-bf6814924577.0-5-0.sandbox-platform-laika -``` - -**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.laika: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.laika: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.laika: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 -``` - ---------------------------------------------------------------------------- - -### 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 [here](/components/dcae-cli/walkthrough/#view-the-platform-generated-configuration). - -``` -$ dcae_cli component dev component-spec.json -Ready for component development -``` - ---------------------------------------------------------------------------- - -## `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 -``` - ---------------------------------------------------------------------------- - -### 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 mh877g -+-------------------------------+---------+-------------------------------------------+--------+----------------------------+ -| Name | Version | Description | Status | Modified | -+-------------------------------+---------+-------------------------------------------+--------+----------------------------+ -| sandbox.platform.laika.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": "realsolcnsl00.dcae.solutioning.homer.att.com", - "docker_host": "realsoldokr00.dcae.solutioning.homer.att.com:2376" -} -``` - ---------------------------------------------------------------------------- - -### 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/platformdoc/docs/components/dcae-cli/quickstart.md b/platformdoc/docs/components/dcae-cli/quickstart.md deleted file mode 100644 index a70cd037..00000000 --- a/platformdoc/docs/components/dcae-cli/quickstart.md +++ /dev/null @@ -1,110 +0,0 @@ -# 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://codecloud.web.att.com/projects/ST_DCAECNTR/repos/dcae-cli/browse) - -## 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 [profile](/components/dcae-cli/commands#activate-a-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 --extra-index-url https://nexus01.research.att.com:8443/repository/solutioning01-mte2-pypi/simple 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 --extra-index-url https://nexus01.research.att.com:8443/repository/solutioning01-mte2-pypi/simple 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 [dcae_cli Commands](/components/dcae-cli/commands). diff --git a/platformdoc/docs/components/dcae-cli/walkthrough.md b/platformdoc/docs/components/dcae-cli/walkthrough.md deleted file mode 100644 index 683bfabd..00000000 --- a/platformdoc/docs/components/dcae-cli/walkthrough.md +++ /dev/null @@ -1,340 +0,0 @@ -# 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 [dcae_cli Commands](/components/dcae-cli/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-input-file-for-dmaap-testing) -* [If needed, Create the input file for *Sourced at Deployment* Testing](#create-input-file-for-sourced-at-deployment-testing) -* [Run the component](#run-the-component) -* [If needed, Create the DTI entry in CONSUL for DTI Reconfiguration Testing](#create-DTI-entry-for-reconfiguration) -* [Undeploy the component](#undeploy-the-component) -* [Publish the component and data_format](#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 - -This walk-through uses example projects that can be found in CodeCloud: - -* [laika](https://codecloud.web.att.com/projects/ST_DCAECNTR/repos/laika/browse) -* [CDAP examples](https://codecloud.web.att.com/projects/ST_DCAECNTR/repos/dcae_cli_examples/browse) - -------------------------------------------------------------------- - -## Add a Data Format -``` -$ dcae_cli data_format add $HOME/laika/data-formats/health.json -``` - -Verify that the data_format was added -``` -$ dcae_cli data_format list | grep laika -| sandbox.platform.laika.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/laika/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.laika | 0.7.0 | docker | Web service used as a stand-alone test DCAE service compone.. | staged | 2017-11-08 20:27:34.168854 | 0 | -+-------------------------------+---------+--------+---------------------------------------------------------------+--------+----------------------------+-----------+ -``` - -------------------------------------------------------------------- - -## 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=realsoldokr00.dcae.solutioning.homer.att.com:2376 -export SERVICE_CHECK_INTERVAL=15s -export CONFIG_BINDING_SERVICE=config_binding_service -export HOSTNAME=ph8547.b599cf0e-75e8-484b-b8e2-557576d77036.0-7-0.sandbox-platform-laika -export CONSUL_HOST=realsolcnsl00.dcae.solutioning.homer.att.com -export CDAP_BROKER=cdap_broker -export SERVICE_NAME=ph8547.b599cf0e-75e8-484b-b8e2-557576d77036.0-7-0.sandbox-platform-laika -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 - `ph8547.b599cf0e-75e8-484b-b8e2-557576d77036.0-7-0.sandbox-platform-laika`). - - -### 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":"realsoldokr00", - "Address": "10.226.1.15", - "Datacenter":"solutioning-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":"135.205.226.126", - "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/ph8547.b599cf0e-75e8-484b-b8e2-557576d77036.0-7-0.sandbox-platform-laika - -{"streams_subscribes": {}, "services_calls": {}, "multiplier": 3, "streams_publishes": {}} -``` - -------------------------------------------------------------------- - -## 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 [Dmaap Connection Object](/components/component-specification/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. For example, there are components whose configuration parameters are to come from DTI events which are only available when the component is deployed. This is established in the [component specification](/components/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 [Dmaap Connection Object](/components/component-specification/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.laika | 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.laika:0.7.0 -DCAE.Docker | INFO | Running image 'nexus01.research.att.com:18443/repository/solutioning01-mte2-docker/dcae-platform/laika:0.7.0' as 'ph8547.dbb13a3c-d870-487e-b584-89929b856b5c.0-7-0.sandbox-platform-laika' -DCAE.Docker.ph8547.dbb13a3c-d870-487e-b584-89929b856b5c.0-7-0.sandbox-platform-laika | INFO | Consul host: realsolcnsl00.dcae.solutioning.homer.att.com - -DCAE.Docker.ph8547.dbb13a3c-d870-487e-b584-89929b856b5c.0-7-0.sandbox-platform-laika | INFO | service name: ph8547.dbb13a3c-d870-487e-b584-89929b856b5c.0-7-0.sandbox-platform-laika - -DCAE.Docker.ph8547.dbb13a3c-d870-487e-b584-89929b856b5c.0-7-0.sandbox-platform-laika | INFO | get_config returned the following configuration: {"streams_subscribes": {}, "multiplier": 3, "services_calls": {}, "streams_publishes": {}} - -DCAE.Docker.ph8547.dbb13a3c-d870-487e-b584-89929b856b5c.0-7-0.sandbox-platform-laika | INFO | * Running on http://0.0.0.0:8080/ (Press CTRL+C to quit) - -DCAE.Docker.ph8547.dbb13a3c-d870-487e-b584-89929b856b5c.0-7-0.sandbox-platform-laika | INFO | 135.205.226.156 - - [08/Nov/2017 23:27:30] "GET /health HTTP/1.1" 200 - - - -Hit Ctrl-C to terminate session. - -^C -DCAE.Docker | INFO | Stopping container 'ph8547.dbb13a3c-d870-487e-b584-89929b856b5c.0-7-0.sandbox-platform-laika' and cleaning up... -``` - -#### Run a component in unattached mode: - -``` -$ dcae_cli -v component run sandbox.platform.laika:0.7.0 -DCAE.Docker | INFO | Running image 'nexus01.research.att.com:18443/repository/solutioning01-mte2-docker/dcae-platform/laika:0.7.0' as 'ph8547.22629ebd-417e-4e61-a9a0-f0cb16d4cef2.0-7-0.sandbox-platform-laika' -DCAE.Run | INFO | Deployed ph8547.22629ebd-417e-4e61-a9a0-f0cb16d4cef2.0-7-0.sandbox-platform-laika. 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 -``` - -------------------------------------------------------------------- - -## Create the DTI Entry for Reconfiguration - -Go the the CONSUL UI for the environment that you are working in. Add a `dti` entry to represent one or more instances of `vnfType-vnfFuncId` for your component. - -For example, in 1802, go (here)[http://zldcrdm5bdcc2cnsl00.2f3fb3.rdm5b.tci.att.com:8500/ui/#/zldcrdm5bdcc2/kv/). - -Do CNTL-F to find your running MS -Click on + to add your entry -Enter your $SERVICE_NAME:dti as the Key -Paste your JSON into the box, remember to `check` the VALIDATE JSON box -Click on CREATE - -Verify that you can retrieve the dti entry you just created as in this example: (Remember to use the 'serviceaddress' and 'serviceport' from above for CONFIG BINDING SERVICE). - -``` -http://135.203.226.126:10000/dti/<service name>`` -``` -(You should see the entry you created above) - -------------------------------------------------------------------- - -## Run the reconfigure script - -Execute the components reconfigure script as defined in the Auxilary section of the component spec, such as in this example: - -``` -/opt/app/reconfigure.sh dti $updated_dti -``` - -(Refer to [DTI Reconfiguration](/components/component-specification/docker-specification/#dti-reconfiguration) - -Verify that your component received and is processed the updated set of vnfType-vnfFuncId instances. - ------------------------------------------------------------------- -## 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.laika:0.7.0` that was deployed above: - -``` -$ dcae_cli -v component undeploy sandbox.platform.laika:0.7.0 -DCAE.Undeploy | WARNING | Undeploying components: 1 -DCAE.Undeploy | WARNING | Undeployed components: 1 -``` - -------------------------------------------------------------------- - -## 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.laika:0.7.0 -Data format has been published - -$dcae_cli component publish sandbox.platform.laika:0.7.0 -Component has been published - -``` -------------------------------------------------------------------- - -## List the catalog contents - -``` -$dcae_cli catalog list - -$ dcae_cli data_format list | grep sandbox -| sandbox.platform.laika | 0.7.0 | docker | Web service used as a stand-alone test DCAE service compone.. | ph8547 | published | 2017-11-13 | -| sandbox.platform.laika.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.laika.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.laika.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.laika.rollcall.response | 0.1.0 | Data format used for the /rollcall endpoint respon.. | published | 2017-11-13 17:46:30.026846 | -``` - diff --git a/platformdoc/docs/components/intro.md b/platformdoc/docs/components/intro.md deleted file mode 100644 index b94fb3e3..00000000 --- a/platformdoc/docs/components/intro.md +++ /dev/null @@ -1,48 +0,0 @@ -# Overview - -DCAE components are services that provide a specific functionality and 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 [CDAP](component-type-cdap.md) and [Docker](component-type-docker.md)). - -### A Component requires one or more data formats. - -A component is a software application that performs a function. It doesn't run independently; it depends 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. - -A component 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 [JSON schema](https://codecloud.web.att.com/projects/ST_DCAECNTR/repos/component-json-schemas/browse/component-spec-schema.json). - -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 [`dcae-cli`](/components/dcae-cli/quickstart.md) is provided to help with onboarding. The high level summary of the onboarding process is: - -1. Defining the [data formats](data-formats.md) if they don't already exist. -2. Defining the [component specification](/components/component-specification/common-specification.md). See [docker](component-specification/docker-specification.md) and [CDAP](component-specification/cdap-specification.md). -3. Use the dcae_cli tool to [add the data formats](/components/dcae-cli/commands/#add-a-data-format) and [add the component](/components/dcae-cli/commands/#add-a-component) to the onboarding catalog. This process will validate them as well. -4. Use the dcae_cli tool to [deploy](/components/dcae-cli/commands/#run-a-component) the component. (The component is deployed to the environment indicated in the [profile](/components/dcae-cli/commands/#activate-a-profile) section). -5. Test the component. Also do pairwise-test the component with any other components it connects with. -7. 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). - diff --git a/platformdoc/docs/concepts/clamp.md b/platformdoc/docs/concepts/clamp.md deleted file mode 100644 index f2eec839..00000000 --- a/platformdoc/docs/concepts/clamp.md +++ /dev/null @@ -1,8 +0,0 @@ - -# Closed Loop / CLAMP - -Closed Loop is a concept where when certain conditions are observed in the network by a component, messages are sent to a particular controller that then responds to those conditions. No manual intervention is needed. Thus the 'loop' is closed automatically. Closed Loop services are configured in the CLAMP UI, which is a non-DCAE component. - -There is no specific configuration in the component specification for closed loop services, and currently it is a manual process between the developer and the CLAMP support team, to discuss which configuration parameters are affected. These parameters can also be policy editable. - -Refer to the [Configuration Grid](/components/component-specification/configuration-grid) for more information. diff --git a/platformdoc/docs/concepts/dti.md b/platformdoc/docs/concepts/dti.md deleted file mode 100644 index 4af71187..00000000 --- a/platformdoc/docs/concepts/dti.md +++ /dev/null @@ -1,10 +0,0 @@ - -# DTI (DCAE Topology Interface) Reconfiguration - -Services that support DTI Reconfiguration are installed (with input provided by a DESIGNER (via SDC UI) or Operations (via Dashboard) to indicate which `vnfType-vnfFuncId` is to be processed by that service. When deployed, the service run but does not collect data until a DTI Event comes in. - -Whenever a network event occurs, resulting in the deployment or undeployment of a `vnfType-vnfFuncId`, it is recorded in A&AI and reported to the DTI Topology VM. The DTI Event is then received by the DTI HANDLER, which uses its values to retrieve one or more reconfiguration blueprints from INVENTORY, and then uploads those blueprint(s) to CLOUDIFY MANAGER. It then creates deployment(s) from those blueprint(s), populates them with the DTI Event values (as inputs), and then executes the install workflow on those deployment(s). - -The platform then executes the reconfigure script (configured in the Auxilary section of the component specification), passing the entire DTI Event to the component. The component can process the individual event or make a call to the CONFIG BINDING SERVICE to retrieve all of the vnfType-vnfFuncIds that are to be processed by the service. - -Refer to the [DTI Reconfiguration](/components/component-specification/docker-specification/#dti-reconfiguration) for more information. diff --git a/platformdoc/docs/concepts/on_sd.md b/platformdoc/docs/concepts/on_sd.md deleted file mode 100644 index 5e6a2f20..00000000 --- a/platformdoc/docs/concepts/on_sd.md +++ /dev/null @@ -1,52 +0,0 @@ -NOTE: THIS PAGE IS A STUB RIGHT NOW. NEEDS EDITING AND WORK. - -# CDAP Cuda Service discovery example. - -NOTE: The below URLs were temporary when the app was deployed, they are no longer valid. -However you can re-create all of this using the commands in https://codecloud.web.att.com/projects/ST_DCAECNTR/repos/dcae_cli_cdap_examples/browse/cuda. - -I deployed CUDA and got back the instance name: b30b7b640fa14539890efa768b4649a2.70900c87-1c82-4690-a0b1-e0aa72cbab84.0-4-1.cdap-cuda.rework-central.dcae.ecomp.att.com. - -If another DCAE service component, like a collector or downstream analytics, were to perform a service lookup on this CUDA app, they would eventually get back a broker URL: http://135.205.226.76:32773/application/b30b7b640fa14539890efa768b4649a2.70900c87-1c82-4690-a0b1-e0aa72cbab84.0-4-1.cdap-cuda.rework-central.dcae.ecomp.att.com - -Which returns a JSON that looks like this: - -``` -{ - "appname":"b30b7b640fa14539890efa768b4649a2.70900c87-1c82-4690-a0b1-e0aa72cbab84.0-4-1.cdap-cuda.rework-central.dcae.ecomp.att.com", - "namespace":"cuda", - "healthcheckurl":"http://135.205.226.76:32773/application/b30b7b640fa14539890efa768b4649a2.70900c87-1c82-4690-a0b1-e0aa72cbab84.0-4-1.cdap-cuda.rework-central.dcae.ecomp.att.com/healthcheck", - "metricsurl":"http://135.205.226.76:32773/application/b30b7b640fa14539890efa768b4649a2.70900c87-1c82-4690-a0b1-e0aa72cbab84.0-4-1.cdap-cuda.rework-central.dcae.ecomp.att.com/metrics", - "url":"http://135.205.226.76:32773/application/b30b7b640fa14539890efa768b4649a2.70900c87-1c82-4690-a0b1-e0aa72cbab84.0-4-1.cdap-cuda.rework-central.dcae.ecomp.att.com", - "connectionurl":"http://135.205.226.110:11015/v3/namespaces/cuda/streams/cuda_appInputStream", - "serviceendpoints":[ - { - "url":"http://135.205.226.110:11015/v3/namespaces/cuda/apps/b30b7b640fa14539890efa768b4649a270900c871c824690a0b1e0aa72cbab84041cdapcudareworkcentraldcaeecompattcom/services/cuda_appOutputDataQuery/methods/allrows", - "method":"GET" - }, - { - "url":"http://135.205.226.110:11015/v3/namespaces/cuda/apps/b30b7b640fa14539890efa768b4649a270900c871c824690a0b1e0aa72cbab84041cdapcudareworkcentraldcaeecompattcom/services/cuda_appOutputDataQuery/methods/lastrow", - "method":"GET" - } - ] -} -``` - -There are important service discovery keys in this JSON. The first is connectionurl. That is the full URL to this application’s stream. The collector can POST data to that URL. - -The second important key is serviceendpoints. These are formed using the information found in the spec. These are, again like connectionurl, full URIs that point to the actual data service. You can try hitting one of those in your browser: http://135.205.226.110:11015/v3/namespaces/cuda/apps/b30b7b640fa14539890efa768b4649a270900c871c824690a0b1e0aa72cbab84041cdapcudareworkcentraldcaeecompattcom/services/cuda_appOutputDataQuery/methods/allrows - -And you will get back the output: -``` -[ - { - "[0]":"{\"start\": 1, \"engagements\": [{\"transcript\": [{\"type\": \"chat.scriptlineSent\", \"senderId\": \"ss754c\", \"content\": \"My SSN is $Identity.ssn. $Identity.name, Thanks for choosing AT\u0026T. My name is $Identity.name and I will be happy to assist you with our plans and services.\", \"iso\": \"2016-05-31T21:59:55-07:00\", \"timestamp\": 1464757195034, \"senderName\": \"agent\"}], \"engagementID\": \"744878782903999181\"}], \"numFound\": 1}" - } -] -``` -This is what we call “service discovery”. A component wants to know how to connect to an application and all they know is that applications name. Through a series of HTTP calls which I’m glossing over here, they eventually get back the URL I showed above which returns that JSON containing all important URLs associated with that application. - -When DMaaP is introduced, this conversation is going to change. In that case, instead of discovering an application directly, you may instead discover a feed that feeds into/out of that app. - - - diff --git a/platformdoc/docs/concepts/policy.md b/platformdoc/docs/concepts/policy.md deleted file mode 100644 index 3838dc22..00000000 --- a/platformdoc/docs/concepts/policy.md +++ /dev/null @@ -1,8 +0,0 @@ - -# Policy (not yet implemented) - -Policy is a concept where certain configuration is specified as being 'set' by Operations via a Policy UI. - -The specific configuration that represents Policy for a given service is designated in the component specification as `policy_editable`, and has a `policy_schema` defined. At any time thereafter, the values can be set in the POLICY UI. Once set, POLICY HANDLER will update the values in CONSUL. If the component is running, it will notify the component that it's policy has changed, and the component will call the CONFIG BINDING SERVICE to obtain a current set of its configuration. - -Refer to the [Configuration Grid](/components/component-specification/configuration-grid) for more information. diff --git a/platformdoc/docs/concepts/service-designer.md b/platformdoc/docs/concepts/service-designer.md deleted file mode 100644 index 5f45f318..00000000 --- a/platformdoc/docs/concepts/service-designer.md +++ /dev/null @@ -1,8 +0,0 @@ - -# Service Design - -Service Design is a concept where the `Service Designer` role uses the `Service Design and Creation (SDC) Tool to compose and services from available components. In doing so, the Service Designer will need to provide certain input that is required by those components. - -The specific configuration that represents input that at Service Designer can provide is designated in the component specification as `designer_editable`. - -Refer to the [Configuration Grid](/components/component-specification/configuration-grid) for more information. diff --git a/platformdoc/docs/glossary.md b/platformdoc/docs/glossary.md deleted file mode 100644 index a48903e1..00000000 --- a/platformdoc/docs/glossary.md +++ /dev/null @@ -1,107 +0,0 @@ -# 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 [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 [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, provides the capability to view platform generated configuration for the component, assist with Dmaap testing, and DTI testing, by enabling the developer to enter DTI input at the command line. - -## Deployment Handler -DCAE Platform Component - Receives Input from DTI Handler, and 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 -AT&T data transportation service platform that supports message-based topics and file-based feeds. Runs locally at the Edge and Centrally. - -## DTI - DCAE Topology Interface -Method of receiving input based on Network element changes (the addtion and removal of VNFs). - -## DTI Event -Data passed between DTI Topology VM and DTI Handler, a notification of a network change - -## DTI Handler -DCAE Platform Component - Receives DTI Event from DTI Topology VM, talks to Deployment Handler - -## DTI Topology VM -DCAE Platform Component - Receives DTI Event from A&AI, when there is a network change - -## 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 Interace where Operations assigns values to configuraton specified for this. - -## Run-Time -Refers to the when a service is running on the platform. Often used in conjunction with DTI events which occur at Run-time. - -## 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/platformdoc/docs/images/IO.graffle b/platformdoc/docs/images/IO.graffle Binary files differdeleted file mode 100644 index 47c18b2a..00000000 --- a/platformdoc/docs/images/IO.graffle +++ /dev/null diff --git a/platformdoc/docs/images/dftool1.png b/platformdoc/docs/images/dftool1.png Binary files differdeleted file mode 100755 index 5f9948f4..00000000 --- a/platformdoc/docs/images/dftool1.png +++ /dev/null diff --git a/platformdoc/docs/images/dftool2.png b/platformdoc/docs/images/dftool2.png Binary files differdeleted file mode 100755 index 5c4e3ff5..00000000 --- a/platformdoc/docs/images/dftool2.png +++ /dev/null diff --git a/platformdoc/docs/images/dmd vision.graffle b/platformdoc/docs/images/dmd vision.graffle Binary files differdeleted file mode 100644 index c6ad0d51..00000000 --- a/platformdoc/docs/images/dmd vision.graffle +++ /dev/null diff --git a/platformdoc/docs/images/dmdvision.png b/platformdoc/docs/images/dmdvision.png Binary files differdeleted file mode 100644 index cc6f195f..00000000 --- a/platformdoc/docs/images/dmdvision.png +++ /dev/null diff --git a/platformdoc/docs/images/io.png b/platformdoc/docs/images/io.png Binary files differdeleted file mode 100644 index 26c5eba9..00000000 --- a/platformdoc/docs/images/io.png +++ /dev/null diff --git a/platformdoc/docs/index.md b/platformdoc/docs/index.md deleted file mode 100644 index 27d7101b..00000000 --- a/platformdoc/docs/index.md +++ /dev/null @@ -1,49 +0,0 @@ -# DCAE Platform - -## Welcome - -This is the home for the documentation for the DCAE platform. - -* Details of the platform's architecture -* User guides for the different roles - - [Component developers](components/intro.md) - -## Background - -DCAE is composed of a platform and services. The DCAE platform is all of the technical pieces responsible for the deployment and the management of DCAE services. The DCAE services are the components responsible for monitoring network services, and data collection and analytics. - -Currently, the current DCAE Platform is a hybrid running both the 'classic (or old) controller' and what's commonly called the 'new controller'. - -### For 1710 - -The classic controller is deploying and managing all CDAP applications, and docker applications that were deployed prior to 1710. -All other docker applications are being deployed and managed by the new controller. - -### For 1802 - -The classic controller is deploying and managing all CDAP applications, and some docker applications that were deployed prior to 1710. -Some docker applications are being migrated from the classic to the new controller. All new docker applications are being deployed and managed by the new controller. - - - -## Contacts - -Name | Email | Role ----- | ----- | ---- -Dan Musgrove | dm4812@att.com | Lead -Shrinkant Acharya | sa8763@att.com | Systems Engineer -Kailas Deshmukh | kd046m@att.com | Technical Lead -Anurag Agarwal | aa0918@att.com | Cloudify Manager Support -Henry Thorpe | ht1659@att.com | CDAP Broker Support -Hong Guan | hg4105@att.com | Clamp Integration Support -Ken Lehner | kl525c@att.com | Consul, Config Binding Service and Docker Container Support -Kuldeep Sharma | ks958r@att.com | DTI Topology VM, Docker Platform and CDAP Cluster Blueprint Support -Lisa Revel | lr0306@att.com | TOSCA Model Tool and Blueprint Generation -Patty Heffner | ph8547@att.com | Onboarding to the DCAE Platform -Shadi Haidar | sh1986@att.com | DTI Handler, Deployment Handler, Inventory, and A&AI Broker Support -Sue Steele | ss477j@att.com | CDAP Platform Support -Swapna Anne | sa9226@att.com | Docker Plugins Support -Terry Schmalzried | ts862m@att.com | Cloudify and CDAP Plugin Support -Tony Hansen | tony@att.com | Postgres Support -William Au | sa998j@att.com | Service Change Handler Support - diff --git a/platformdoc/mkdocs.yml b/platformdoc/mkdocs.yml deleted file mode 100644 index 35d660b0..00000000 --- a/platformdoc/mkdocs.yml +++ /dev/null @@ -1,39 +0,0 @@ -site_name: DCAE Platform -site_url: https://github.research.att.com/pages/DCAE-Rework/dcae-rework.github.io/ - -repo_url: https://github.research.att.com/DCAE-Rework - -# http://squidfunk.github.io/mkdocs-material/ -theme: material - -pages: - - Home: 'index.md' - - Change Log: 'changelog.md' - - Architecture: - - Technologies: 'architecture/pieces.md' - - Services: 'architecture/services.md' - - Service Discovery: 'architecture/service-discovery.md' - - Component Developers: - - Overview: 'components/intro.md' - - Concepts: - - Closed Loop/CLAMP: 'concepts/clamp.md' - - DTI Reconfiguration: 'concepts/dti.md' - - Policy: 'concepts/policy.md' - - Service Design: 'concepts/service-designer.md' - - Requirements/Guidelines: - - CDAP: 'components/component-type-cdap.md' - - Docker: 'components/component-type-docker.md' - - Component Specification: - - Common Elements: 'components/component-specification/common-specification.md' - - CDAP Specific: 'components/component-specification/cdap-specification.md' - - Docker Specific: 'components/component-specification/docker-specification.md' - - DMaaP connection objects: 'components/component-specification/dmaap-connection-objects.md' - - Streams Quick Reference: 'components/component-specification/streams-grid.md' - - Configuration Types Quick Reference: 'components/component-specification/configuration-grid.md' - - Examples: 'components/component-specification/examples-grid.md' - - Data Format Specification: 'components/data-formats.md' - - dcae-cli Tool: - - Quickstart: 'components/dcae-cli/quickstart.md' - - Commands: 'components/dcae-cli/commands.md' - - Walk-through: 'components/dcae-cli/walkthrough.md' - - Glossary: 'glossary.md' |
