4

Hono is deployed on a Minikube cluster (I followed https://www.eclipse.org/hono/getting-started/ to set up Hono locally) and Ditto is running on localhost. I tried to follow this tutorial and adapt it so it works for local deployment. Unfortunately I'm unable to connect Ditto to the AMQP endpoint of my local Hono instance, which I tried the following way: 

curl -X POST -i -u devops:foobar -H 'Content-Type: application/json' -d '{
  "targetActorSelection": "/system/sharding/connection",
  "headers": {
    "aggregate": false
  },
  "piggybackCommand": {
      "type": "connectivity.commands:testConnection",
      "connection": {
      "id": "hono-example-connection",
      "connectionType": "amqp-10",
      "connectionStatus": "open",
      "failoverEnabled": true,
      "uri": "amqp://consumer%40HONO:verysecret@honotry:15672",
      "sources": [
        {
          "addresses": [
        "telemetry/test_tenant"
          ],
          "authorizationContext": ["nginx:ditto"]
        }
      ]}
    }
}' http://localhost:8080/devops/piggyback/connectivity?timeout=8000

"honotry" resolves to the IP address of the service "hono-dispatch-router-ext".

I get the return:

{"?":{"?":{"type":"devops.responses:errorResponse","status":504,"serviceName":null,"instance":null,"payload":{"status":504,"error":"connectivity:connection.failed","message":"The Connection with ID 'hono-example-connection' failed to connect.","description":"honotry: System error"}}}}

I don't know why I get this error message.

I'm able to connect the local Ditto instance to Hono Sandbox: 

curl -X POST -i -u devops:foobar -H 'Content-Type: application/json' -d '{
  "targetActorSelection": "/system/sharding/connection",
  "headers": {
    "aggregate": false
  },
  "piggybackCommand": {
      "type": "connectivity.commands:testConnection",
      "connection": {
      "id": "hono-example-connection",
      "connectionType": "amqp-10",
      "connectionStatus": "open",
      "failoverEnabled": true,
      "uri": "amqp://consumer%40HONO:verysecret@hono.eclipse.org:15672",
      "sources": [
        {
          "addresses": [
        "telemetry/test_tenant"
          ],
          "authorizationContext": ["nginx:ditto"]
        }
      ]}
    }
}' http://localhost:8080/devops/piggyback/connectivity?timeout=8000

I get the return:

{"?":{"?":{"type":"connectivity.responses:testConnection","status":200,"connectionId":"hono-example-connection","testResult":"successfully connected + initialized mapper"}}}

It is also possible to connect the local Hono AMQP Endpoint using the command line client:

java -jar hono-cli-*-exec.jar --hono.client.host=honotry --hono.client.port=15672 --hono.client.username=consumer@HONO --hono.client.password=verysecret --spring.profiles.active=receiver --tenant.id=test_tenant

Does anyone have an idea how to fix that problem? Thank you in advance!

EDIT: 

kubectl get service -n hono

returns

NAME                                      TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                           AGE
hono-adapter-amqp-vertx                   LoadBalancer   10.98.166.86     10.98.166.86    5672:32672/TCP,5671:32671/TCP     38d
hono-adapter-amqp-vertx-headless          ClusterIP      None             <none>          <none>                            38d
hono-adapter-http-vertx                   LoadBalancer   10.109.22.54     10.109.22.54    8080:30080/TCP,8443:30443/TCP     38d
hono-adapter-http-vertx-headless          ClusterIP      None             <none>          <none>                            38d
hono-adapter-mqtt-vertx                   LoadBalancer   10.102.80.84     10.102.80.84    1883:31883/TCP,8883:30883/TCP     38d
hono-adapter-mqtt-vertx-headless          ClusterIP      None             <none>          <none>                            38d
hono-artemis                              ClusterIP      10.109.194.251   <none>          5671/TCP                          38d
hono-dispatch-router                      ClusterIP      10.96.42.49      <none>          5673/TCP                          38d
hono-dispatch-router-ext                  LoadBalancer   10.98.212.66     10.98.212.66    15671:30671/TCP,15672:30672/TCP   38d
hono-grafana                              ClusterIP      10.97.9.216      <none>          3000/TCP                          38d
hono-prometheus-server                    ClusterIP      10.102.174.24    <none>          9090/TCP                          38d
hono-service-auth                         ClusterIP      10.101.250.119   <none>          5671/TCP                          38d
hono-service-auth-headless                ClusterIP      None             <none>          <none>                            38d
hono-service-device-connection-headless   ClusterIP      None             <none>          <none>                            38d
hono-service-device-registry              ClusterIP      10.108.127.7     <none>          5671/TCP,8443/TCP                 38d
hono-service-device-registry-ext          LoadBalancer   10.108.60.120    10.108.60.120   28080:31080/TCP,28443:31443/TCP   38d
hono-service-device-registry-headless     ClusterIP      None             <none>          <none>                            38d

honotry is set to 10.98.212.66 in /etc/hosts.

Amanda Schoefl
  • 41
  • 3
  • 1
    Hi Amanda, have you already tried to use the IP of `hono-dispatch-router-ext` instead of `honotry`in the connection uri? How did you deploy ditto? Using minikube aswell? – Yannic Klem Jan 14 '20 at 14:26
  • Are you running `minikube tunnel` for your Hono instance? Can you also post the output of `kubectl get service -n hono`? – Kai Hudalla Jan 14 '20 at 16:29
  • Thank you for your answers and sorry for my late reply! @YannicKlem: I did try to use the IP address, but it is not permitted by ditto without a host name. I don't use minikube for deployment of ditto. I cloned the git repo and executed 'docker-compose up -d'. – Amanda Schoefl Jan 17 '20 at 08:55
  • @KaiHudalla 'minikube tunnel' is running. I added the requested output to my original post. – Amanda Schoefl Jan 17 '20 at 08:56
  • @AmandaSchoefl Ditto does allow the use of the IP but in that case you need to set the `validateCertificates`field of the connection explicitly to `false` because the default value is true. Have you tried to resolve the hostname "honotry" inside the connectivity container of ditto? – Yannic Klem Jan 17 '20 at 10:39
  • @YannicKlem even with `validateCertificates` set to `false` I get the following return: `{"?":{"?":{"type":"devops.responses:errorResponse","status":400,"serviceName":null,"instance":null,"payload":{"status":400,"error":"connectivity:connection.configuration.invalid","message":"The configured host '10.98.212.66' may not be used for the connection.","description":"It is a blacklisted hostname which may not be used."}}}}` – Amanda Schoefl Jan 17 '20 at 11:07
  • Oh, Sorry! Yes there is a "blacklisting" of local IPs which was introduced to prevent that http forwarding can be used to create an endless loop. To disable this you would have to set the environment variable `CONNECTIVITY_CONNECTION_BLACKLISTED_HOSTNAMES` to an empty string for the connectivity container. – Yannic Klem Jan 17 '20 at 12:10
  • Thank you, the host is not blacklisted anymore, but I still get: `{"?":{"?":{"type":"devops.responses:errorResponse","status":504,"serviceName":null,"instance":null,"payload":{"status":504,"error":"connectivity:connection.failed","message":"The Connection with ID 'hono-example-connection' failed to connect.","description":"Could not establish a connection on '10.98.212.66:15672'. Make sure the endpoint is reachable and that no firewall prevents the connection."}}}}` – Amanda Schoefl Jan 17 '20 at 12:32
  • Looks like you can't access this IP from within the docker network. This is more a docker networking question then. You could have a look at https://stackoverflow.com/a/31328031/2576531. – Yannic Klem Jan 17 '20 at 13:39

0 Answers0