...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

Overview

This feature introduces the ability for independent deployment of the DCAE Components.  In the past, all 10 existing DCAE Components were deployed as sub-charts of the dcaegen2 chart.  If a user wanted to deploy a subset of the components, it would require editing and recompiling the Helm charts.  As of Frankfurt Release, we switched to using the Helm component model which allows us to control the deployment of each component by setting a corresponding value in an overrides file, thereby avoiding the need to recompile the charts.

This feature is available in Frankfurt Release per  

Suggested Usage

Use a helm override file (-f option) with the --install option to helm upgrade for managing dcae components.  e.g.

helm upgrade --install dev-dcae local/dcaegen2 --namespace onap -f ~/dcae_vijay4.yaml

The --install flag is needed if the charts have not been deployed previously, and seems not to hurt if they have been deployed.  In general, this command will adjust the dcaegen2 sub-components that are running based on what is enabled in the override file.  

File ~/dcae_vijay4.yaml has the following contents:

dcae-bootstrap:
  enabled: false
dcae-cloudify-manager:
  enabled: true
dcae-config-binding-service:
  enabled: true
dcae-healthcheck:
  enabled: true
dcae-redis:
  enabled: false
dcae-servicechange-handler:
  enabled: false
dcae-inventory-api:
  enabled: false
dcae-deployment-handler:
  enabled: true
dcae-policy-handler:
  enabled: false
dcae-dashboard:
  enabled: true

In this example, most dcae components will be deployed, but dcae-service-change-handler, dcae-policy-handler and dcae-bootstrap would not be deployed because their enabled flag is false.

The resulting deployment should look similar to this:

Image Added

DCAEGEN2 Pre-requisites

When deploying dcaegen2, it can be useful to first deploy it's pre-requisite dependencies.  This allows the user to iterate on dcaegen2 without having to re-deploy the pre-requisites, thereby saving time.   

Start with an overrides file that enables the pre-requisite components. e.g. dcae_depend.yaml:

aaf:
  enabled: true
consul:
  enabled: true
msb:
  enabled: true
multicloud:
  enabled: true
dcaegen2:
  enabled: false
dmaap:
  enabled: true
message-router:
  enabled: true
dmaap-bc:
  enabled: true
dmaap-dr-node:
  enabled: true
dmaap-dr-prov:
  enabled: true
policy:
  enabled: true
sdc:
  enabled: false

Then, use helm deploy to get these components running.

helm deploy dev local/onap --namespace onap -f ~/dcae_depend.yaml

This should result in each of the components getting deployed, and the output of helm list should be:

$ helm list
NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE
dev 1 Tue Dec 17 19:40:14 2019 DEPLOYED onap-5.0.0 El Alto onap
dev-aaf 1 Tue Dec 17 19:40:15 2019 DEPLOYED aaf-5.0.0 onap
dev-consul 1 Tue Dec 17 19:40:17 2019 DEPLOYED consul-5.0.0 onap
dev-dcae 1 Thu Dec 19 20:03:51 2019 DEPLOYED dcaegen2-6.0.0 onap
dev-dmaap 1 Tue Dec 17 19:40:19 2019 DEPLOYED dmaap-5.0.0 onap
dev-msb 1 Tue Dec 17 19:46:06 2019 DEPLOYED msb-5.0.0 onap
dev-multicloud 1 Tue Dec 17 19:46:08 2019 DEPLOYED multicloud-5.0.0 onap
dev-policy 1 Tue Dec 17 19:46:10 2019 DEPLOYED policy-5.0.0 onap

Then dcaegen2 can be deployed (installed) using the technique described above..

helm deploy is tricky!

If you want to deploy dcaegen2 using helm deploy, it is possible but there is a trick.   We observed that under the covers, helm deploy calls helm upgrade with a generated overrides file.  In order for the sub-component settings to be included in this generated overrides file, they must be indented under the dcaegen2 section of any overrides file you specify on the command line.  For example the dcaegen2 section of the overrides file, dcae_component_deploy.yaml looks like this:

dcaegen2:
  enabled: true
  dcae-bootstrap:
    enabled: false
  dcae-cloudify-manager:
    enabled: true
  dcae-config-binding-service:
    enabled: true
  dcae-healthcheck:
    enabled: false
  dcae-redis:
    enabled: false
  dcae-servicechange-handler:
    enabled: false
  dcae-inventory-api:
    enabled: true
  dcae-deployment-handler:
    enabled: true
  dcae-policy-handler:
    enabled: false
  dcae-dashboard:
    enabled: true

and can be referenced with the helm deploy command, such as:

helm deploy dev local/onap --namespace onap -f ~/dcae_component_deploy.yaml

Alternatively, use helm install

Use a helm override file (-f option to helm install) for managing dcae components.  e.g.

helm install --debug local/dcaegen2 --name dev-dcae --namespace onap -f ~/dcae_frankfurt.yaml --timeout 900

File ~/dcae_frankfurt.yaml has the following contents:

dcae-bootstrap:
  enabled: true
dcae-cloudify-manager:
  enabled: true
dcae-config-binding-service:
  enabled: true
dcae-healthcheck:
  enabled: true
dcae-redis:
  enabled: true
dcae-servicechange-handler:
  enabled: false
dcae-inventory-api:
  enabled: true
dcae-deployment-handler:
  enabled: true
dcae-policy-handler:
  enabled: true
dcae-dashboard:
  enabled: false

In this example, most dcae components will be deployed, but dcae-service-change-handler and dcae-dashboard would not be deployed because their enabled flag is false.

The resulting deployment should look similar to this:

Image Added