Page History

...

1. 1.DMaaP will maintain a single set of Helm Charts in the oom/kubernetes repo.  Said a different way, we will strive to not maintain separate  DMaaP Central charts and DMaaP Edge charts.
   1. The DMaaP Helm charts will continue to be maintained as a single oom kubernetes directory, with sub-directories for each component.
2. 2. The "central" site will always be deployed before any edge sites.
   1. The Edge deployment (and operation) will rely on central ONAP services (e.g. AAF)
   2. This will allow a human (at least) to capture any values representing central deployment details (such as a K8S gateway IP address)
3. All DMaaP components will continue to be deployed in the "central" k8s.  The details of what components will be deployed at any Edge, and how it will be deployed are the subject of this page.
4. An "edge" site can be deployed any time after the "central" site.
5. Not all edge sites need be deployed at the same time.  
6. As a Platform Service, DMaaP will be deployed before any application/microservice.
7. SSL Server Certificates will be created in advance of deployment, and not generated at deployment time.  (This is a feature for El Alto)
8. By convention, the kubernetes cluster name will be used as the name of the site.

Requirements

1. An Edge-deployed DMaaP component must be able to route to a central-deployed service.  Examples include:
   1. dr-node periodically syncs with dr-prov
   2. dr-node authenticates publish requests using aaf
   3. message-router authenticates client requests using aaf
   4. dbc-client makes request to dmaap-bc API during post-install provisioning
   5. Edge mirrormaker subscribes to central message-router kafka
2. Localized DR Routing between a Data File Collector (DFC) and a PM Mapper deployed in the same Edge X.
   1. Localized DR Routing means DR Node is deployed in the same Edge site so data doesn't need to leave the site.
   2. DFC will be a publisher to a feed provisioned at deployment time.
   3. PM Mapper will be a subscriber provisioned at deployment time.
   4. The feed should be unique per site so that when there are multiple sites, PM Mapper only receives its locally produced data.
3. Localized messaging from PM Mapper and DFC.  This will signal DFC that a file was processed.
   1. Localized messaging implies a Message Router instance in the same edge location.
   2. PM Mapper will a publisher provisioned at deployment time 
   3. DFC will be a subscriber provisioned at deployment time.
   4. Communication will utilize an authenticated topic in the MR deployed in the same edge site. 
      1. PM Mapper and DFC will use AAF credentials to authenticate.
      2. PM Mapper identity will be authorized to publish on the topic
      3. DFC identity will be authorized to subscribe on the topic
4. Inter-site messaging from PM Mapper to VES perf3gpp
   1. Inter-site messaging means sending a message from an edge location publisher to a central location subscriber.
   2. PM Mapper, deployed at Edge,  will be a publisher using AAF credentials
   3. VES perf3gpp, deployed in Central, will be a subscriber using AAF credentials
   4. Communication will utilize an authenticated topic on the MR deployed in the same edge site.
      1. PM Mapper and DFC will use AAF credentials to authenticate.
      2. PM Mapper identity will be authorized to publish on the topic
      3. VES perf3gpp identity will be authorized to subscribe on the topic
   5. Furthermore, messages on this topic will be replicated to the central MR instance.
   6. Are there any other subscribers?  (esp, are there any other at edge?)

...