As a mesh administrator, with a mesh ("mesh 1") that is federated with one or more other service meshes ("mesh 2") - which may reside in the same cluster or a different cluster, I want to connect one of my services (we'll call it "Service A") with a service in mesh 2 (We'll call it "Service B"). These are two different services, with different identities.

For the purposes of this story, it can be assumed that the user has sufficient admin privileges over both service meshes to connect the two services.

From the perspective of mesh 1, I am "importing" service B from mesh 2, which is federated with mesh 1. From the perspective of mesh 2, they are "exporting" service B to be available to mesh 1. Once complete, the Service A should be able to call Service B, without the knowledge or care that it resides in a separate mesh or cluster.

Acceptance Criteria:

• From mesh 1's perspective:
  • I am able to validate that service A is able to connect to service B via some "oc" commands as well as Kiali. 
  • Kiali should visualize that service A is connected to service B in mesh 2, showing both the service and the fact that it resides in a different mesh (with some form of mesh identifier). If the service is in a different cluster, this should also be indicated in some manner, with some form of cluster identification.
  • I should be able to observe traffic (via metrics, traces) that is being sent between Service A and B in the "other" mesh, in the same manner that I would monitor traffic between services within my own mesh. 
  • Note: I do NOT expect to be able to monitor traffic beyond the imported service (only service B) in the other mesh.
• From mesh 2's perspective:
  • Same as above, but swap Service A and B.

This will more refinement for service identity, traffic management, mTLS, etc. Those may be separate user stories though.