Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

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   OOM-1574 - Getting issue details... STATUS .


Suggested Usage

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:


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 techniques described in other sections.

helm deploy is tricky!


  • No labels