The gap analysis has been added to the Akraino ICN OpenNESS wiki page as following:

https://wiki.akraino.org/display/AK/OpenNESS+19.12+Investigation#OpenNESS19.12Investigation-Cross-Nodecommunication

By changing the common name and myURN of openvino consumer,  openvino-cons-app and openvino-cons-app2 will use different version of docker image openvino-cons-app, and they both can run and consume the same producer. The logs are below:

[root@master consumer]# kubectl get pod
NAME READY STATUS RESTARTS AGE
openvino-cons-app 1/1 Running 0 111s
openvino-cons-app2 1/1 Running 0 17s
openvino-prod-app 1/1 Running 4 2d18h

[root@master consumer]# kubectl logs openvino-cons-app
[setupvars.sh] OpenVINO environment initialized
2020/01/13 02:22:53 OpenVINO Consumer Started
2020/01/13 02:22:53 WebSocket establishment successful
2020/01/13 02:22:53 Subscribed to notification: openvino-inference 1.0.0
2020/01/13 02:22:53 Subscribed to notification: terminate 1.0.0
2020/01/13 02:23:44 Rx notification – vehicle-detection-adas-0002 | CPU
2020/01/13 02:24:44 Rx notification – pedestrian-detection-adas-0002 | CPU

[root@master consumer]# kubectl logs openvino-cons-app2
[setupvars.sh] OpenVINO environment initialized
2020/01/13 02:24:21 OpenVINO Consumer Started
2020/01/13 02:24:41 WebSocket establishment successful
2020/01/13 02:24:46 Subscribed to notification: openvino-inference 1.0.0
2020/01/13 02:24:46 Subscribed to notification: terminate 1.0.0
2020/01/13 02:24:46 Rx notification – pedestrian-detection-adas-0002 | CPU

[root@master consumer]# kubectl describe pod openvino-cons-app | grep Image
Image: openvino-cons-app:1.0
Image ID: docker://sha256:b691b193662743554ab9c240ea5ed3dcb21765695fa0d27afaae1be24c6715d4

[root@master consumer]# kubectl describe pod openvino-cons-app2 | grep Image
Image: openvino-cons-app:2.0
Image ID: docker://sha256:8163d1887505ef6790902032f796ee326ed0beb958f3ba6736113214ac5aeece

A map is used to store consumer connections as following:
https://github.com/open-ness/edgenode/blob/master/pkg/eaa/main.go#L23

The common name is used as the key of the map:
https://github.com/open-ness/edgeapps/blob/master/openvino/consumer/cmd/main.go#L42
https://github.com/open-ness/edgenode/blob/master/pkg/eaa/api_consumer.go#L57

As the openvino-cons-app and openvino-cons-app2 is 2 instances of the same microservice, they share the same common name. When openvino-cons-app2 starts successfully and try to register with eaa, eaa will detect whether this common name has registerd or not as following:
https://github.com/open-ness/edgenode/blob/master/pkg/eaa/api_consumer.go#L37
Because the common name has been registered by openvino-cons-app, eaa will close the connection of openvino-cons-app as following:
https://github.com/open-ness/edgenode/blob/master/pkg/eaa/api_consumer.go#L41

Finding a bug within openness:
If we run multiple instances of same consumer, only one consumer can work. 

For example:
consumer1 and consumer2 are 2 instances of the same consumer. Assume we run consumer1 firstly. After we run consumer2, consumer1 will lost the connection and restart. After consumer1 restart successfully, consumer2 will lost connection and restart. 
                   node1                                                     node2                 
                                                                                                                          
                      eaa                                                                                              
                                                                                                                         
   producer1    consumer1                                     consumer2 

The logs are below:
[root@master consumer]# kubectl logs openvino-cons-app2
[setupvars.sh] OpenVINO environment initialized
2020/01/10 08:42:28 OpenVINO Consumer Started
2020/01/10 08:42:28 WebSocket establishment successful
2020/01/10 08:42:28 Subscribed to notification: openvino-inference 1.0.0
2020/01/10 08:42:28 Subscribed to notification: terminate 1.0.0
2020/01/10 08:42:30 Failed to read message from WebSocket: websocket: close 1012: New connection request, closing this connection
./start.sh: line 10: fg: no job control

[root@master consumer]# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
openvino-cons-app    1/1    Running   3   63m    10.16.0.17    node1 <none> <none>
openvino-cons-app2   0/1   Error         4   62m    10.16.0.18    node2 <none> <none>
openvino-prod-app    1/1    Running   0   74m    10.16.0.3      node1 <none> <none>

Because edge apps on different edge node all can access service eaa, the consumer can consume the service provided by producer which is on a different node.

For example:
producer1 is located in node1 and consumer2 is located on node2. The networking flow will be:
   producer1 -> service eaa -> pod eaa
   consumer2 -> service eaa -> pod eaa
                   node1                                                     node2                 
                                                                                                                          
                      eaa                                                                                              
                                                                                                                         
                producer1                                             consumer2     

eaa is deployed as a deployment and only 1 eaa will be deployed:
https://github.com/open-ness/edgecontroller/blob/master/kube-ovn/openness.yaml#L41

Because all edge apps will access only 1 eaa, it doesn't matter that eaa is stateful. 

For example:
only 1 eaa is deployed on node1. producer1 and producer2 will activate the new service with eaa. consumer1 and consumer2 will consume services stored in eaa. Because all the information are stored in only 1 eaa, there won't be issues. 

                      node1                                                     node2                 
                                                                                                                          
                      eaa                                                                                              
                                                                                                                         
         producer1      consumer1                        producer2    consumer2           
                                                                                                                            

Edge apps will access eaa through eaa.openness (name.namespace) which is a kubernetes service:
https://github.com/open-ness/edgecontroller/blob/master/kube-ovn/openness.yaml#L18

For example: as following links show, openvino consumer will access http://eaa.openness:443/auth for authentication.
https://github.com/open-ness/edgeapps/blob/master/openvino/consumer/cmd/main.go#L24
https://github.com/open-ness/edgeapps/blob/master/openvino/consumer/cmd/main.go#L66

Edge applications must introduce themselves to OpenNESS framework and identify if they would like to activate new edge services or consume an existing service. Edge Application Agent (EAA) component is the handler of all the edge applications hosted by the OpenNESS edge node and acts as their point-of-contact. 

OpenNESS-awareness involves (a) authentication, (b) service activation/deactivation, (c) service discovery, (d) service subscription, and (e) Websocket connection establishment. The Websocket connection retains a channel for EAA for notification forwarding to pre-subscribed consumer applications. Notifications are generated by "producer" edge applications and absorbed by "consumer" edge applications.

The sequence of operations for the producer application:

1. Authenticate with OpenNESS edge node
2. Activate new service and include the list of notifications involved
3. Send notifications to OpenNESS edge node according to business logic

The sequence of operations for the consumer application:

1. Authenticate with OpenNESS edge node
2. Discover the available services on OpenNESS edge platform
3. Subscribe to services of interest and listen for notifications