6 replies
Has anyone been able to get hono running in k3s? I using the helm chart to deploy with zero modifications. But there seems to be dns issues, the device registry fails with
03:11:27.159 [vert.x-eventloop-thread-1] DEBUG o.e.h.s.a.d.DelegatingAuthenticationService - readiness check failed to resolve Authentication service address [eclipse-hono-service-auth]: Search domain query failed. Original hostname: 'eclipse-hono-service-auth' failed to resolve 'eclipse-hono-service-auth.hono.svc.cluster.local'I have not done any debuggin yet, just checking quickly if someone has seen this before?
7 replies
@ctron would you mind taking a (final) look at eclipse/packages#132 so that we can merge the PR?
Looks good to me
Hello packages community!
I attempted to follow the instructions for installing the Cloud2edge package (@ https://www.eclipse.org/packages/packages/cloud2edge/installation/) on a minikube cluster.
Unfortunately, I ran into an issue while attempting said installation...
I issued the following command:
$ helm install -n $NS --wait --timeout 10m $RELEASE eclipse-iot/cloud2edge
And, after a few minutes, I got this:
Error: rpc error: code = Unavailable desc = transport is closing
Any recommendations with regards to how I should troubleshoot this?
Better yet, any ideas why this is happening?
@sophokles73 I increased the timeout even further and this time around I was able to verify that all pods appear to be working. The command to ingest data appears to be working:
curl -i -u demo-device@org.eclipse.packages.c2e:demo-secret -H 'application/json' --data-binary '{
"topic": "org.eclipse.packages.c2e/demo-device/things/twin/commands/modify",
"headers": {},
"path": "/features/temperature/properties/value",
"value": 45
}' http://192.168.99.103:30080/telemetry
HTTP/1.1 202 Accepted
content-length: 0
Unfortunately, I cannot get anything at the other end:
curl -u ditto:ditto -w '\n' http://192.168.99.103:31831/api/2/things/org.eclipse.packages.c2e:demo-device
{"status":408,"error":"gateway:command.timeout","message":"The Command reached the specified timeout of 60,000ms.","description":"Try increasing the command timeout"}
Partial (relevant) output of the setCloud2EdgeEnv script:
...
export HTTP_ADAPTER_IP="192.168.99.103"
export HTTP_ADAPTER_PORT_HTTP="30080"
export HTTP_ADAPTER_PORT_HTTPS="30443"
...
export DITTO_API_IP="192.168.99.103"
export DITTO_API_PORT_HTTP="31831"
values.yaml file the mounted secrets should be specified at hono.amqpMessagingNetworkExample.broker.artemis.extraSecretMounts, and so i did, but the secrets were not mounted. Then i checked the artemis-deployment.yaml where it specifies that it picks up the values from .Values.amqpMessagingNetworkExample.broker. After seeing this i tried to set my secrets in the hono.amqpMessagingNetworkExample.broker.extraSecretMounts (notice i removed "artemis") value and it worked! I am new to Kubernetes so maybe i am missing something, but i wanted to share this to know what you think.
curl -u ditto:ditto -w '\n' http://192.168.99.103:31831/api/2/things/org.eclipse.packages.c2e:demo-device
{"status":408,"error":"gateway:command.timeout","message":"The Command reached the specified timeout of 60,000ms.","description":"Try increasing the command timeout"}
@robmontalvojr that sounds like the Ditto cluster did not form itself correctly, I can not explain such a timeout error otherwise
could you check the http://<ditto-ip>:<port>/status/health endpoint if all of Ditto's services are reporting "UP"?
values.yaml file. You need to provide the full set of properties for the particular client, i.e. not just the properties that you want to change.
Hi there... I don't know if this is the right place to ask my question, please feel free to redirect me otherwise...
I set up the cloud2edge package and I'm now struggeling to send a custom "event" from a device connected to Hono via Ditto to a queue connected to Ditto.
In Ditto-speak that would be the "smokeDetected" Message mentioned here: https://www.eclipse.org/ditto/basic-messages.html
My setup is as follows:
MQTT client (representing the device) <-> Hono <-> Ditto <-> RabbitMQ (via Ditto connection service)
If I publish a MQTT message to the "event topic" I get the following error logged in the ditto-connectivity container:
2020-11-09 09:51:36,503 INFO [] o.e.d.s.c.m.MessageMappingProcessorActor akka://ditto-cluster/system/sharding/connection/5/hono-connection-for-idealcustomer/pa/$v/c1/messageMappingProcessor - Got DittoRuntimeException 'json.format.invalid' when ExternalMessage was processed: The headers did not contain a value for mandatory header with key <ditto-message-direction>! -
2020-11-09 09:51:36,514 INFO [] o.e.d.s.c.m.a.AmqpConsumerActor akka://ditto-cluster/system/sharding/connection/5/hono-connection-for-idealcustomer/pa/$v/c1/amqpConsumerActor-0-event%2Fidealcustomer-03 - Acking <ID:AMQP_NO_PREFIX:EventSenderImpl-16> with original external message headers=<{orig_adapter=hono-mqtt, device_id=org.anization:thething, qos=1, creation-time=1604911896475, message-id=ID:AMQP_NO_PREFIX:EventSenderImpl-16, content-type=application/octet-stream, to=event/idealcustomer, orig_address=event}>, isSuccess=<true>, ackType=<1 accepted>I tried to add the "ditto-message-direction" to the MQTT payload in a "headers" member and I tried configure it in the tenants Hono-Ditto-Connection configuration as a fix Header mapping, but still no luck:
"headerMapping": {
"hono-device-id": "{{ header:device_id }}",
"content-type": "{{ header:content-type }}",
"ditto-message-direction": "FROM"
},I'm not quite sure where the problem (or my lack of understanding) is located, my current assumption is:
- MQTT doesn't support headers, so Hono is not forwarding any to Ditto
- Ditto checks the headers of the incoming message before it looks at the payload and complains about the missing header
- the Header mapping is somehow not used / working
What is the way this is supposed to work? Is it maybe something I need to configure in Hono? Please let me know, if you need any further information (e. g. the connection configuration or the MQTT message payload, I left it out for brevity)
{
"topic": "org.anization/thething/things/live/messages",
"headers": {
"ditto-message-direction":"FROM"
},
"path": "/"
}OK, thanks for the hint regarding the path! That brought me to read up on the Ditto protocol details for messages, so I got the payload straight:
{
"topic": "org.anization/thething/things/live/messages/mytestsubject",
"headers": { },
"path": "/inbox/messages/mytestsubject"
}And that worked!
