-
Bug
-
Resolution: Done
-
Blocker
-
maistra-2.1.0
-
None
-
False
-
False
-
-
Sprint 9, Sprint 10, Sprint 11
I'm deploying the example federation script using two clusters on AWS.
The mesh1 service is successfully imported into mesh2:
$ oc -n mesh2-system get importedservicesets mesh1 -o json | jq .status
{
"importedServices": [
{
"exportedName": "mongodb.bookinfo.svc.mesh2-exports.local",
"localService": {
"hostname": "mongodb.mesh2-bookinfo.svc.mesh1-imports.local",
"name": "mongodb",
"namespace": "mesh2-bookinfo"
}
},
{
"exportedName": "ratings.bookinfo.svc.mesh2-exports.local",
"localService": {
"hostname": "ratings.mesh2-bookinfo.svc.mesh1-imports.local",
"name": "ratings",
"namespace": "mesh2-bookinfo"
}
}
]
}
However, a curl command from a mesh2 pod (in mesh2-bookinfo namespace) that tries to reach the imported service fails to resolve the host:
$ oc -n mesh2-bookinfo exec -it sleep-6d646957b7-74psz -c sleep -- curl -v ratings.mesh2-bookinfo.svc.mesh1-imports.local:9080 * Could not resolve host: ratings.mesh2-bookinfo.svc.mesh1-imports.local * Closing connection 0 curl: (6) Could not resolve host: ratings.mesh2-bookinfo.svc.mesh1-imports.local command terminated with exit code 6
This should work fine, right?
Weirdly, the instructions in the end if the install.sh work fine:
1. Run this command in the mesh1 cluster: oc logs -n mesh1-bookinfo deploy/ratings-v2 -f 2. Run this command in the mesh2 cluster: oc logs -n mesh2-bookinfo deploy/ratings-v2 -f 3. Open http://istio-ingressgateway-mesh2-system.apps.jwendell-33.servicemesh.devcluster.openshift.com/productpage 4. Refresh the page several times and observe requests hitting either the mesh1 or the mesh2 cluster.
I mean, I confirm I see the requests coming into the mesh1 pod. How so? Perhaps because connections are coming through an ingress gateway, whereas in my case I'm calling curl from within a pod?
I've attached the config dump for the sleep pod (the one where I run curl from)
There are no Sub-Tasks for this issue.