Page Comparison

...

1. 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)
   
   1. Include central deployed DMaaP services with existing node ports in proxy config: dr-prov, message-router, dmaap-bc
   2. Expose central deployed DMaaP service on node port and add to proxy configuration: dr-node
   3. NOTE: proxy can subsequently route by FQDN (for HTTP only).  
2. K8S External Service.  Deploy services at Edge which map to central services.
   1. REF: https://cloud.google.com/blog/products/gcp/kubernetes-best-practices-mapping-external-services
3. Add entries for central services into /etc/hosts on Edge pods so they can route properly
4. Provision some external DNS service that is able to resolve to required IP addresses in other k8s cluster
   1. Will require establishing a convention for FQDN.  eg.  <Release>-<service>.<namespace>
   2. Convention should leverage assumptions of using same value for Release and k8s cluster name.
5. Determine how clients can specify FQDN (service name) but designate IP address to use.  
   1. See  --resolve option in curl for example of how this might work.
6. Apply k8s thinking to DMaaP component design:
   1. Abandon the DR publish redirect protocol and simply use dr-node service instead.
      1. if dr-node is local to the cluster, then client will route to local dr-node pod for publishing (which is desired)
      2. if dr-node isn't local to cluster, then client will route to central dr-node via proxy  (fallback)
   2. Change dr-prov algorithm for distributing prov data to dr-node so dr-prov doesn't need to know how to address every pod
      1. consider simple periodic polling by dr-node
      2. consider using an MR topic to trigger dr-node to poll for prov data
   3. migrate to ELK design for logging, removes need for dr-prov to gather logs from each dr-node.  (already in progress)

...