...

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.

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.

To access the design Web UI, for example, a user would use the URL : http://ingress_controller_address:ingress_controller_port/nifi.
ingress_controller_address is the the IP address or DNS FQDN of the ingress controller and
ingress_controller_port is the port on which the ingress controller is listening for HTTP requests.  (If the port is 80, the HTTP default, then there is no need to specify a port.)

There are two additional internal endpoints that users need to know, in order to configure a registry client and a distribution target in the design tool's controller settings.

Using DCAE MOD without an Ingress Controller

<to be supplied><To be expanded later; deployment of MOD will be via Helm charts>

2.    Configuring DCAE mod

...

At this point, you can create a new bucket using the wrench tool in the UI and let’s say we name this new-bucket

Creating a bucket is no longer needed.  The Helm installation automatically creates a bucket.

Now let’s access the Nifi (DCAE designer) UI - http://<hostname>/nifi

...

curl -X POST -u acumos:integration2019 http://localhost/onboarding/dataformats     -H "Content-Type: application/json" -d @df-request-model-b1-reporting-subscribe.json

curl -X POST -u acumos:integration2019 http://localhost/onboarding/components     -H "Content-Type: application/json" -d @components-request-model-b1-reporting.json

In a Helm deployment the hostname would not be localhost.  It would be the IP address (or DNS FQDN if there is one) for one of the Kubernetes nodes.

More posting requests for data formats and components

...

These jars should now be available for you to use in the nifi UI as processors

In a Helm deployment <genprocessor_host> would be the IP address (and port, if it's not the default port 80) for a Kubernetes node.

3.    Design & Distribution Flow

...

Add a registry client. The Url will be as shown for the current docker compose files. This url is on the internal docker network. This might change when not using docker compose.

See above for the correct URL to use in a Helm environment.

Now enter the process group and drag and drop components that we need into the Process group.

...

Once we have the desired flow checked in, we can go ahead and set the distribution target in the controller settings

See above for the correct URL.

d. Submit/ Distribute the flow:

...

e. Checking the components in the DCAE inventory

In a Helm deployment, inventory is not exposed externally.  These steps should probably refer to the DCAE dashboard, which allows viewing blueprints in inventory.

curl -X GET -k https://135.207.216.182:32346/dcae-service-types | jq . | less

...