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
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.
Disable AAF
Authentication via AAF is the default setting in Dublin DMaaP. But sometimes it is useful to disable this check and the dependency on AAF (e.g. for a demo setup). This section provides some instructions for disabling AAF for the various DMaaP components.
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 (i.e. no data persistence if pod is restarted) which is handy for quick tests and full redeployments.
To disable Postresql:
- edit oom/kubernetes/dmaap/components/dmaap-bc/values.yaml
- change the attribute PG.enabled to false
- recompile the dmaap helm charts. i.e. from kubernetes directory, make dmaap
- deploy dmaap
Disable AAF Authentication
Dublin introduces dependencies on AAF for API authentication. However, there may be times when you want to avoid
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)