Kubernetes Deployment and a Kubernetes Service) that make up a running
instance of the microservice.
-Beginning with the Honolulu release, DCAE is migrating to a new approach
-for deploying DCAE microservices. Instead of using Cloudify with a
-Cloudify blueprint for each microservice, DCAE will use Helm to deploy
-microservices. Each microservice will have a Helm chart instead of a
-Cloudify blueprint. In the Honolulu release, four DCAE microservices
-(the VES and HV-VES collectors, the PNF registration handler, and the
-TCA Gen2 analytics service) moved to Helm deployment. All four of these
-are deployed “statically”–that is, they are deployed when DCAE is
-installed and run continuously.
+In the Honolulu release, DCAE began migrating to a new approach for
+deploying DCAE microservices. Instead of using Cloudify with a
+Cloudify blueprint for each microservice, DCAE began using Helm to
+deploy microservices. This migration is now complete, and all
+DCAE microservices have a Helm chart instead of a Cloudify blueprint.
DCAE Service Templates - Introduction
-------------------------------------
It would be possible to write a Helm chart for each microservice, each
-completely unrelated. We are taking a different approach. We are
+completely unrelated to the others. We are taking a different approach. We are
providing shared Helm templates that (approximately) create the same
Kubernetes resources that the Cloudify plugin created when it processed
a blueprint. Creating a Helm chart for a microservice involves setting
image: onap/org.onap.dcaegen2.services.prh.prh-app-server:1.5.6
+**imageRepositoryOverride**:
+
+Alternative repository for the Docker image for the microservice.
+Optional. If this value is set, the Docker image for the microservice
+will be pulled from the repository specified by this value, instead of
+from the repository set by ``repositoryGenerator.repository``. Note that
+this alternative repository is used only for the microservice image and
+not for other images (such as images for initContainers). Note also that
+the alternative repository must not use any form of authentication,
+because there is no way to provide credentials for the repository.
+
+Example:
+
+::
+
+ imageRepositoryOverride: "myrepo.example.org:5000"
+
**global.pullPolicy** and **pullPolicy**:
These settings control when
converted to JSON before being pushed to Consul or mounted as a file. If
not present, defaults to an empty object ({}).
-*Note: Due to a bug in the Honolulu release (DCAEGEN2-2782), it is
-necessary to supply an ``applicationConfig`` in the ``values.yaml`` for
-a microservice even if the microservice does not have any configuration.
-The workaround is to supply an empty configuration:*
-
-::
-
- applicationConfig: {}
-
-*This is being fixed in the Istanbul release.*
-
**applicationEnv:**
Microservice-specific environment variables to be
**certDirectory:**
Path to the directory in the microservice’s
-container file system where TLS-certificate information from AAF should
+container file system where TLS-certificate information from CMPv2 should
be mounted. This is an optional field. When it is present, the
dcaegen2-services-common deployment template will set up an
initContainer that retrieves the certificate information into a shared
certDirectory: /etc/ves-hv/ssl
-**tlsServer:**
-
-Boolean flag. If set to ``true``, the
-dcaegen2-services-common deployment will configure the initContainer
-described above to fetch a server certificate for the microservice. If
-set to ``false``, the initContainer will fetch only a CA certificate for
-the AAF certificate authority. ``tlsServer`` is optional. The value
-defaults to ``false``. ``tlsServer`` is ignored if ``certDirectory`` is
-not set.
-
**logDirectory:**
Path to the directory where the microservice writes
dcaePolicySyncImage: onap/org.onap.dcaegen2.deployments.dcae-services-policy-sync:1.0.1
-**consulLoaderImage:**
-
-Name and tag of the consul loader image to be
-used. Required. The consul loader image runs in an initContainer that
-loads application configuration information into Consul. The image
-repository is set using the OOM common
-``repositoryGenerator.repository`` template. Normally this points to the
-ONAP image repository, but it can be overridden on a global basis or a
-per-chart basis. See the OOM documentation for more details.
-
-Example:
-
-::
-
- consulLoaderImage: onap/org.onap.dcaegen2.deployments.consul-loader-container:1.1.0
-
-**tlsImage:**
-
-Name and tag of the TLS initialization image to be used.
-Required if the microservice is configured to act as a TLS client and/or
-server using AAF certificates. The TLS initialization image runs in an
-initContainer and pulls TLS certificate information from AAF and stores
-it in a volume on the microservice’s pod. The image repository is set
-using the OOM common ``repositoryGenerator.repository`` template.
-Normally this points to the ONAP image repository, but it can be
-overridden on a global basis or a per-chart basis. See the OOM
-documentation for more details.
-
-Example:
-
-::
-
- tlsImage: onap/org.onap.dcaegen2.deployments.tls-init-container:2.1.0
-
**certProcessorImage:**
Name and tag of the CMPv2 certificate
correct common name/SAN.
Also note that if the chart for ``dcae-ves-collector`` has been pushed into a Helm repository, the ``helm install`` command can refer to the
-repository (for instance, ``local/dcae-ves-collector``) instead of using the chart on the local filesystem.
\ No newline at end of file
+repository (for instance, ``local/dcae-ves-collector``) instead of using the chart on the local filesystem.
+
+
+Dynamic Topic and Feed Provisioning
+-----------------------------------
+This section introduces details on creation of dynamic Dmaap Topics in Message Router and Feeds in Data Router via DCAE helm charts.
+
+Provisioning support through DCAE common-service template
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When using DCAE common-service template in microservice chart ``deployment.yaml`` file it is required to include ``dcaegen2-services-common.microserviceDeployment`` template.
+The dcaegen2-services-common include necessary ``common.dmaap.provisioning.initContainer`` template which provisions topics and feeds on Dmaap Message Router and Data Router.
+
+Example : Including ``dcaegen2-services-common.microserviceDeployment`` template in ``deployment.yaml``.
+
+::
+
+ {{ include "dcaegen2-services-common.microserviceDeployment" . }}
+
+The ``common.dmaap.provisioning.initContainer`` template included in DCAE ``dcaegen2-services-common.microserviceDeployment`` makes use of
+dmaap-bc client image to create Topics on Message Router and Feeds on Data Router microservice, with the help of ``dbc-client.sh`` script,
+it uses Bus Controller REST API to create resources.
+
+If the resource creation is successful via script, the response is logged in file with appropriate naming convention.
+
+.. note::
+ The configuration provided via ``values.yaml`` file, is consumed by ``common.dmaap.provisioning.initContainer`` template which runs two
+ init-container, First named init-dmaap-provisioning for creating resources on Dmaap, Second named init-merge-config which updates application config
+ with response generated as an outcome of operation by init-dmaap-provisioning container.
+
+The figure below shows Dmaap Topics, Feeds Provisioning architecture via dcae-service-common helm charts.
+
+..
+ The following diagram has been created on https://app.diagrams.net/. There is an editable version of the diagram
+ in repository under path docs/sections/images/dmaap_provisioning_architecture_diagram.drawio, import file to update diagram.
+
+.. image:: images/dmaap_provisioning.png
+
+Configuration to be added in ``values.yaml`` file.
+
+.. note::
+ For more information on attributes that are set in ``values.yaml`` for Data Router Feed, Publisher and Subscriber, Message Router Topic creation,
+ you can refer DMaaP Bus Controller API documentation at: https://docs.onap.org/projects/onap-dmaap-buscontroller/en/latest/apis/api.html
+
+Dmaap Data Router Feeds creation input can be provided in below format. It consumes list of Feeds.
+
+.. note::
+ For DR Feed creation except ``feedName``, ``feedDescription``, ``feedVersion`` avoid update on other attributes.
+ All other attributes are mandatory, contains required default values.
+
+::
+
+ drFeedConfig:
+ - feedName: bulk_pm_feed
+ owner: dcaecm
+ feedVersion: 0.0
+ asprClassification: unclassified
+ feedDescription: DFC Feed Creation
+
+Once the Feeds creation is successful we can attach Publisher and Subscriber to Feeds.
+
+Dmaap Data Router Publisher config:
+
+.. note::
+ For DR Publisher creation except ``feedName`` avoid update on other attribute.
+ All other attributes are mandatory, contains required default values.
+
+::
+
+ drPubConfig:
+ - feedName: bulk_pm_feed
+ dcaeLocationName: loc00
+
+Dmaap Data Router Subscriber config:
+
+.. note::
+ For DR Subscriber creation except ``feedName`` avoid update on other attributes.
+ Attribute username, userpwd will be updated via init-merge-config init-container of ``common.dmaap.provisioning.initContainer`` template.
+ In case dcae-pm-mapper microservice is not the Subscriber, attribute deliveryURL need to be updated and privilegedSubscriber can be updated to False.
+ All other attributes are mandatory, contains required default values.
+
+::
+
+ drSubConfig:
+ - feedName: bulk_pm_feed
+ decompress: True
+ username: ${DR_USERNAME}
+ userpwd: ${DR_PASSWORD}
+ dcaeLocationName: loc00
+ privilegedSubscriber: True
+ deliveryURL: https://dcae-pm-mapper:8443/delivery
+
+Dmaap Message Router Topics creation input can be provided in below format. It consumes list of Topics.
+Also we can attach Message Router Publisher and Subscriber at same time while creation of Topic.
+
+.. note::
+ For Message Router Topic creation except ``topicName`` and ``topicDescription`` avoid update on other attributes.
+ All other attributes are mandatory, contains required default values.
+
+::
+
+ mrTopicsConfig:
+ - topicName: PERFORMANCE_MEASUREMENTS
+ topicDescription: Description about Topic
+ owner: dcaecm
+ tnxEnabled: false
+ clients:
+ - dcaeLocationName: san-francisco
+ clientRole: org.onap.dcae.pmPublisher
+ action:
+ - pub
+ - view
+
+Volume configuration for configMap to be provided in ``values.yaml`` file.
+
+::
+
+ volumes:
+ - name: feeds-config
+ path: /opt/app/config/feeds
+ - name: drpub-config
+ path: /opt/app/config/dr_pubs
+ - name: drsub-config
+ path: /opt/app/config/dr_subs
+ - name: topics-config
+ path: /opt/app/config/topics
+
+
+For example directory containing ``dcae-datafile-collector``, ``dcae-pm-mapper`` chart under
+dcaegen2-services in OOM repository we can find examples for Feed and Topic creation.
+
+Provisioning support through DCAE When using custom deployment.yaml
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When using custom ``deployment.yaml`` it is required explicitly to include ``common.dmaap.provisioning.initContainer`` template in
+initContainer specs of ``deployment.yaml`` file.
+
+Example : Including ``common.dmaap.provisioning.initContainer`` template in ``deployment.yaml`` file.
+
+::
+
+ {{- include "common.dmaap.provisioning.initContainer" . | nindent XX }}
+
+Note also need to take care of the ``Volumes`` that are required to be mounted on Application Pod in ``deployment.yaml``.
+
+::
+
+ {{- include "common.dmaap.provisioning._volumes" . | nindent XX -}}
+
+Configuration to be added in ``values.yaml`` file is similar to described in ``Provisioning support through DCAE common-service template``.
+
+Removal of Data Router Feed, Publisher and Subscriber Or Message Router Topic
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+DCAE does not support automatic removal of Feed, Publisher and Subscriber from Data Router or Topic from Message Router at present.
+So it is the responsibility of operator to manually remove Feeds and associated Publisher or Subscriber from Data Router and Topics
+from Message Router after uninstalling microservice charts which created resources on installation.
+
+Reference to DMAAP Bus Controller API documentation to figure out steps for manual removal of resources.
+https://docs.onap.org/projects/onap-dmaap-buscontroller/en/latest/apis/api.html
Code Review / dcaegen2.git / blobdiff