DCAE MOD User Guide
| Table of Contents |
|---|
Types of Users and Usage Instructions:
...
...
Types of Users and Usage Instructions:
Short Video Series available at : https://www.youtube.com/playlist?list=PLj-oRfbkqkfnN_2vnfhivCesJ118SA_zG
Demo day demonstration recording and slides available at : https://lf-onap.atlassian.net/wiki/display/DW/2020-04-16+DCAE+Demo
Sr.No | User | Usage Instructions |
1. | Developers who are looking to onboard their mS | · Access the Nifi Web UI url provided to you · Follow steps 2.b to 2.d · You should be able to see your microservices in the Nifi Web UI by clicking and dragging ‘Processor’ on the canvas, and searching for the name of the microservice/component/processor. |
2. | Designers who are building the flows through UI and triggering distribution | · Access the Nifi Web UI url provided to you · Follow steps 3 to the end of the document |
3. | Infrastructure/ Admins who want to stand up DCAE Mod and validate it | · Follow start to the end |
1. Deployment of DCAE MOD components via Helm charts
The DCAE MOD components are deployed using the standard ONAP OOM deployment process. When deploying ONAP using the helm deploy command, DCAE MOD components are deployed when the dcaemod.enabled flag is set to true, either via a --set option on the command line or by an entry in an overrides file. In this respect, DCAE MOD is no different from any other ONAP subsystem.
The default DCAE MOD deployment relies on an nginx ingress controller being available in the Kubernetes cluster where DCAE MOD is being deployed. The Rancher RKE installation process sets up a suitable ingress controller. In order to enable the use of the ingress controller, it is necessary to override the OOM default global settings for ingress configuration. Specifically, the installation needs to set the following configuration in an override file:
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
#Global ingress configuration ingress: |
...
...
enabled: |
...
true |
...
virtualhost: |
...
...
|
...
baseurl: |
...
"simpledemo.onap.org" |
When DCAE MOD is deployed with an ingress controller, several endpoints are exposed outside the cluster at the ingress controller's external IP address and port. (In the case of a Rancher RKE installation, there is an ingress controller on every worker node, listening at the the standard HTTP port (80).) These exposed endpoints are needed by users using machines outside the Kubernetes cluster.
...
Configuration Item | Endpoint URL |
Registry client | http://dcaemod-nifi-registry:18080 |
Distribution target | http://dcaemod-runtime-api:9090 |
As OOM/ingress template has been updated in Guilin release to enable virtual host, MOD API's and UI access via ingress should use dcaemod.api.simpledemo.onap.org
Add entry for dcaemod.simpledemo.onap.org in /etc/hosts with the correct IP (any of K8S node IP can be specified)
Using DCAE MOD without an Ingress Controller
<to be supplied>Not currently supported.
2. Configuring DCAE mod
Our demo is hosted on 10.12.7.116. The IP Address for the purpose of this demo will hence be 10.12.7.116. In case of other deployments, we would have used the IP Address, or the DNS FQDN, if there is one, for one of the Kubernetes nodes.
Now let’s access the Nifi (DCAE designer) UI - http://10dcaemod.12simpledemo.7onap.116org/nifi/
a) Get the artifacts to test and onboard.
...
A sample Component DCAE-VES-Collector : https://git.onap.org/dcaegen2/collectors/ves/tree/dpo/spec/vescollector-componentspec.json
A sample Data Format : https://git.onap.org/dcaegen2/collectors/ves/tree/dpo/data-formats/VES-45.2728.24-dataformat.json
For the purpose of onboarding, a Sample Request body should be of the type -
...
These requests would be of the type-
curl -X POST http://<onboardingapi host>/onboarding/dataformats -H "Content-Type: application/json" -d @<filepath to request>
curl -X POST http://<onboardingapi host>/onboarding/components -H "Content-Type: application/json" -d @<filepath to request>
In our case,
curl -X POST http://10dcaemod.12simpledemo.7onap.116org/onboarding/dataformats -H "Content-Type: application/json" -d @<filepath to request>
curl -X POST http://10dcaemod.12simpledemo.7onap.116org/onboarding/components -H "Content-Type: application/json" -d @<filepath to request>
You can download the Components and Data Formats for the demo from –
Components:
https://git.onap.org/dcaegen2/collectors/ves/tree/dpo/spec/vescollector-componentspec.json
https://git.onap.org/dcaegen2/analytics/tca-gen2/tree/dcae-analytics/dpo/tcagen2_spec.json
Corresponding Data Formats:
https://git.onap.org/dcaegen2/collectors/ves/tree/dpo/data-formats
https://git.onap.org/dcaegen2/analytics/tca-gen2/tree/dcae-analytics/dpo/
...
c) Verify the resources were created using
curl -X GET http://10dcaemod.12simpledemo.7onap.116org/onboarding/dataformats
curl -X GET http://10dcaemod.12simpledemo.7onap.116org/onboarding/components
d) Verify the genprocessor (which polls onboarding periodically to convert component specs to nifi processor), converted the component
Open http://10dcaemod.12simpledemo.7onap.116org/nifi-jars in / in a browser.
These jars should now be available for you to use in the nifi UI as processors.
3. Design & Distribution Flow
a) Configure Nifi Registry url
...
b) Add distribution target which will be the runtime api url
Once we have the desired flow checked in, we can go ahead and set the Set the distribution target in the controller settings
...
Finally, the generated Blueprint can be deployed.
You can use/import the attached input configurations files to deploy. Drag and Drop these sample JSON files to fill in the configuration values.
NOTE 1: Increase memory limit to 512Mi
NOTE 2: Verify image URL
| View file | ||
|---|---|---|
|
|
| View file | ||||
|---|---|---|---|---|
|
