Page Comparison

...

1. Definitions:  
   
   1. Dublin introduces the notion of a multi-cloud deployment consisting of a single "central" kubernetes  High Availablility (HA) installation, and 0 or more "edge" kubernetes installations.  
   2. Geo-redundancy applies to a multi-site central k8s deployment.  This shouldn't be confused with a multi-site ONAP deployment consisting of central and edge sites.
2. Assumptions:
   
   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. The "central" site will always be deployed before any edge sites.
      1. The Edge deployment (and operation) may rely on central ONAP services
      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.
3. Helm configuration overrides will be collected in a single file (e.g. dmaap-edge.yaml) and delivered to oom/kubernetes/onap/charts/resource/environments.  Examples of what kinds of overrides will be present in this file include:
   1. Setting the standard enabled indicator to true for dmaap, but false for other components.
      

      dmaap:
        enabled: true

   2. Setting an edge indicator to drive any edge-specific logic.  TBD if this is really useful - hopefully other overrides in this file are edge specific.
   3. Setting the values for a central service which may be needed at the edge.  Known examples include:
      1. Message Router must be configured to access the central AAF instance.  (DR Node may have this requirement in the near future)
      2. Data Router Node must be configured to access the central DR Prov
      3. Both MR and DR Node must register with central Bus Controller
   4. Setting scaling values appropriate to the edge.  e.g. perhaps a single kafka broker is appropriate at the edge
4. DMaaP Chart changes
   
   1. Reorder charts:
      1. Bus Controller must be up and running if other components are going to register with it.  Jira to remove any dependencies on MR.
      2. MR
      3. Mirror Maker
      4. DR Prov
      5. DR Node  (DR Prov must be up for Node to retrieve provisioning info)
   2. Post-install hooks:
      1. Bus controller:
         1. POST <central dmaap-bc>/webapi/dmaap
         2. POST <central dmaap-bc>/webapi/dcaeLocation (for central)
      2. MR:
         1. POST <central dmaap-bc>/webapi/mr_clusters  DMAAP-534  Jira to add kafka brokers to endpoint
      3. DR Node
         1. POST <central dmaap-bc>/webapi/dr_node   DMAAP-534
5. Central K8S Deployment
6. Central DMaaP Deployment
   1. Use k8s cluster name as the Release.  e.g. "central"
   2. Deploy aaf
   3. Deploy dmaap
   4. Deploy dcae
   5. Deploy VES perf3gpp via dcae
7. Edge K8S Deployment
8. Edge DMaaP Deployment
   1. Use k8s cluster name as the Release.  e.g. "edge1"
   2. deploy dmaap
   3. deploy PM Mapper via dcae

Related articles

5G Use Case (Dublin)

...