...
- Extend the configuration of the Jack's proxy to include DMaaP services. Note: Current capability will route from edge to central. (See Jack's demo from ~ 0:29:40)
- Include central deployed DMaaP services with existing node ports in proxy config: dr-prov, message-router, dmaap-bcbc (Completed: see https://gerrit.onap.org/r/#/c/87710/)
- Expose central deployed DMaaP service on node port and add to proxy configuration: dr-nodenode (Completed: see https://gerrit.onap.org/r/#/c/87710/)
- NOTE: proxy can subsequently route by FQDN (for HTTP only).
- K8S External Service. Deploy services at Edge which map to central services.
- Add entries for central services into /etc/hosts on Edge pods so they can route properly
- Provision some external DNS service that is able to resolve to required IP addresses in other k8s cluster
- Will require establishing a convention for FQDN. eg. <Release>-<service>.<namespace>
- Convention should leverage assumptions of using same value for Release and k8s cluster name.
- Determine how clients can specify FQDN (service name) but designate IP address to use.
- See --resolve option in curl for example of how this might work.
- Apply k8s thinking to DMaaP component design:
- Abandon the DR publish redirect protocol and simply use dr-node service instead.
- if dr-node is local to the cluster, then client will route to local dr-node pod for publishing (which is desired)
- if dr-node isn't local to cluster, then client will route to central dr-node via proxy (fallback)
- Change dr-prov algorithm for distributing prov data to dr-node so dr-prov doesn't need to know how to address every pod
- consider simple periodic polling by dr-node
- consider using an MR topic to trigger dr-node to poll for prov data
- migrate to ELK design for logging, removes need for dr-prov to gather logs from each dr-node. (already in progress)
- Abandon the DR publish redirect protocol and simply use dr-node service instead.
...