...
Using a Postgres database
ONAP already has a Helm-based mechanism for deploying instances of Postgres and setting up credentials for client access. We use this mechanism to create the DCAE postgres database already. The drawback to this approach is that it creates a separate instance of Postgres each time it is used. There has been work on setting up shared instances of databases in ONAP, but so far Postgres has not been included in those efforts.
As we move DCAE service component deployment to Helm, we should make use of the ONAP project-wide Helm mechanisms. If DCAE has certain special requirements, we should work to enhance the project-wide mechanisms.
Implementation Phases
Service components deployed at DCAE installation time
As of the Guilin release, we are deploying 6 service components at DCAE installation time, via a script that runs on the DCAE k8s-bootstrap-container:
tcagen2 (org.onap.dcaegen2.analytics.tca-gen2.dcae-analytics-tca-web)
ves-tls (org.onap.dcaegen2.collectors.ves.vescollector)
prh (org.onap.dcaegen2.services.prh.prh-app-server)
hv-ves (org.onap.dcaegen2.collectors.hv-ves.hv-collector-main)
holmes_rules (holmes/rule-management)
holmes_engine (holmes/engine-management)
The first four components do not use any extended capabilities (DMaaP, policies, Postgres database), so they can be moved to a Helm-based deployment without implementing solutions for the extended capabilities. The last two components use the DCAE postgres database. Moving these components will require some alternative solution for the database. The Holmes components are managed by the Holmes project, which is separate from the DCAE project. The Holmes project will need to address the issue of handling the Postgres database differently.
For ONAP R8 ("Honolulu"), we propose creating the Helm templates and charts needed to deploy the first four components on the list above.
Service components deployed on demand
...