Page History

...

Open Issues

REF

Status

Discussion

1

Open

DNS Update for inter-site routing

We have several examples of an edge component which needs to communicate to a central service. Mike suggested that edge DNS might be updated such that edge clients could resolve to central services. This might satisfy a common need across several components. e.g. access to central AAF comes to mind

05/02:

Another alternative was demoed by DCAE where an nginx container is deployed at edge site which proxies service traffic to the relevant NodePort on the central k8s cluster.

This may be suitable for some of DMaaP components (as a POC) but not a preferred solution.

Work is ongoing in OOM to provide this (with input from the community)

Jira

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	OOM-1572

2

Open

Location discovery

Bus Controller manages dcaeLocations as the name of different sites. What mechanism can be used to:

a) register dcaeLocations when each k8s cluster is deployed.

b) serve as an attribute when MR and DR clients are provisioned. Current expectation is that there is some k8s info in A&AI API that might be useful.

05/02:

Agreement from DCAE on requirement to involve all ONAP components (AAI, OOF, etc) to find a suitable solution here.

Defined use-case defined here

Jira

server	ONAP JIRA
serverId	425b2b0a-557c-3c0c-b515-579789cceedb
key	OOM-1579

3

Open

Relying on Helm chart enabled flag

2/12:

"Mike,

Last week we discussed using a helm configuration override file to control which components get deployed at edge.

The idea being we would set enabled: false for a component that shouldn’t be deployed.

But dmaap chart actually consists of several sub-charts, each of these sub-charts correspond to a specific dmaap component which we may want to deploy at edge or not.

So, curious if you know the syntax for this – I haven’t been able to find a reference for how enabled is actually used, and I don’t see that value referenced in our charts so not clear what is reading it.

Wondering if our edge config override would be something like:

  dmaap:

    dmaap-message-router:

      enabled: true

    dmaap-bus-controller:

      enabled: false

    dmaap-dr-prov:

      enabled: false

    dmaap-dr-node:

      enabled: true

or, do charts for our individual components need to be top level directories under oom/kubernetes in order to use the enabled flag?"

2/13: From Mike Elliot:

"I’ve been trying to allow for the conditional control over the dr-prov and dr-node as well, with no success.

Still investigating options for this. Hope to have a solution on this by EOD."

05/02:

Current chart structure allows deployment of individual components. (BC, MR, DR).

One caveat to this is a dependency on AAF being reachable by BC & MR. (DR soon to follow)

See the DMaaP Deployment Guide - Dublin for more details.

4

Open

05/02:

Helm chart edge deploy.

POC procedure demoed using multiple "kube-config --contexts" to target the edge site/cluster during helm deploy. (Inter cluster security may come into play here also)

"edge charts" may require several override params to cater for the following.

dcaeLocation (see issue 2)
pod specs - size, resources, etc
readiness configuration?
potential service endpoint changes/proxies?

5

Open

05/02:

Need to identify if all of the required services (logstash, AAF, dr-node, mr-kafka, etc) have exposed NodePorts available for bi-directional traffic between sites.

Development

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
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

...

View file

name	DMaaP Edge - Dublin.pptx
height	250

Info

Space shortcuts

Page tree

Versions Compared

Old Version 7

New Version 8

Key

Open Issues

Development

Related articles