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

Version 1 Next »

This page and sub-pages are intended to capture Notes for deploying DMaaP components.  Due the number of integration points between DMaaP components, and also with AAF and OOM, there sometimes is a need for some minor edits to get a successful deployment.

General

Use WindRiver Test AAF instead of a local deployment

By default, the DMaaP OOM charts will assume a locally deployed AAF instance.  Sometimes it is convenient to avoid an AAF deployment and simply use the AAF Test instance in WindRiver.

TBD

Disable persistence (Postgresql) for dmaap-bc

By default, dmaap-bc utilizes the common postgresql chart.  This starts up several additional pods.  But dmaap-bc does support a non-PG option which is handy for quick tests and redeployments.

To disable Postresql:

  1. edit oom/kubernetes/dmaap/components/dmaap-bc/values.yaml
  2. change the attribute PG.enabled to false
  3. recompile the dmaap helm charts.  i.e. from kubernetes directory, make dmaap
  4. deploy dmaap


Increase Helm Timeout

Depending on your environment, the deployment of all the components takes a while and can easily exceed the default helm timeout.  Recommend adding --timeout 900 to your helm install command line.

Release Combinations

Earlier combinations not included.

As of March 29, 2019 (AAF 2.1.8, dbc-client 1.0.5, dmaap-bc 1.1.2, message-router 1.1.12)

AAF 2.1.8 bootstrap is missing some required permissions. 

Symptoms: 

  • Authenticated topic provisioning via dmaap-bc does not succeed, and so mirrormaker pod is unable to start.
  • dmaap-bc pod log says "/opt/app/dmaapbc/ok_to_exit does not exist.  Sticking around..."   
  • If you login to a shell on dmaap-bc pod and examine /opt/app/dmaapbc/logs/ONAP/error.log, there will be an Error about service credentials not being valid for  AAF connection. 


Resolution:

  1.  Deploy AAF separately first.
  2. In AAF GUI add:

role create org.onap.dmaap-bc.service
perm grant org.onap.dmaap-bc.api.access * read org.onap.dmaap-bc.service
perm grant org.onap.dmaap.mr.access * * org.onap.dmaap-bc.service
perm grant org.onap.dmaap.mr.topic * view org.onap.dmaap-bc.service
perm create org.onap.dmaap.mr.topic * * org.onap.dmaap-bc.service
perm create org.onap.dmaap-dr.feed * * org.onap.dmaap-bc.service
perm create org.onap.dmaap-dr.sub * * org.onap.dmaap-bc.service
perm create org.onap.dmaap.mr.topicFactory :org.onap.dmaap.mr.topic:org.onap.dmaap.mr create,destroy org.onap.dmaap-bc.service
role user add org.onap.dmaap-bc.service dmaap-bc@dmaap-bc.onap.org
role user add org.onap.dmaap-bc.api.Controller dmaap-bc@dmaap-bc.onap.org

NOTES:

  1. the message-router-mirrormaker pod is dependent on topic provisioning and AAF permissions being granted, which is done as a result of the message-router post-install job.  Sometimes this sequence takes a while and the message-router-mirrormaker pod status gets in a crashback loop.  Patience: if all the steps above are taken, it should eventually reach a ready state.  However, it will never succeed if the full topic provisioning wasn't successful.
  2. depending on your environment, the deployment of all the components takes a while and can easily exceed the default helm timeout.  Recommend adding --timeout 900 to your helm install command line.
  • No labels