Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Kai Hudalla
    @sophokles73
    I was asking exactly because of the fact that I let you wait for this for so long. Sorry again for that. I was just wondering if there was anything else that you wanted to wait for ... I'll merge it ...
    ah, you already merged it. Thanks.
    Barry Kaplan
    @memelet
    Are there any plans to factor out the hono charts per service? Or at least factor out the adapters so they can more easily run on edge nodes? It seems the single hono helm chart assumes that all hono adapters will always be run in the cloud k8 cluster. Yet the chart has comments about allowing adapters to connect from outside the k8 cluster.
    6 replies
    Kai Hudalla
    @sophokles73
    @dejanb Hi Dejan, any chance we can use a more recent Quarkus version than 1.6.1? Looks like 1.8.1 is already available ... Based on the fact that we (currently) use Quarkus as a works-with dependency only, there shouldn't be an issue regarding the IP log.
    Dejan Bosanac
    @dejanb
    Sure thing. I'll give it a try in the coming days
    Barry Kaplan
    @memelet
    anybody having zoom issues with the meeting?
    Barry Kaplan
    @memelet
    whoops, sorry, I’m an hour early
    Barry Kaplan
    @memelet

    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
    Vasanth Balakrishnan
    @vasanth-bk
    Yes I have seen and raised this issue in GitHub #146. Please see my 2nd attachment in the issue #146 showing the DNS issue.
    Dirk Van Haerenborgh
    @vhdirk
    We have Hono running on a single-node k3s cluster. Adapters all start pretty much instantly
    So far I haven't experienced any big issues. Not from Hono's side or from k3s' side.
    Vasanth Balakrishnan
    @vasanth-bk
    Have you deployed Prometheus also alongside hono ?
    Dirk Van Haerenborgh
    @vhdirk
    ah, no, we have not
    Barry Kaplan
    @memelet
    does anybody know how the hono deployment built into enmasse compares/relates to this deployment?
    Dejan Bosanac
    @dejanb
    Anybody have host privileges to start community meeting?
    Kai Hudalla
    @sophokles73
    @ctron would you mind taking a (final) look at eclipse/packages#132 so that we can merge the PR?
    Jens Reimann
    @ctron

    @ctron would you mind taking a (final) look at eclipse/packages#132 so that we can merge the PR?

    Looks good to me

    robmontalvojr
    @robmontalvojr

    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?

    Kai Hudalla
    @sophokles73
    @robmontalvojr Are you running minikube inside a VM? If so, make sure to provide enough CPU. the Cloud2Edge package's pods require 3 CPUs to run ...
    Also, when deploying the package for the first time, all container images need to be downloaded which might take some time, depending on your bandwidth. Thus, it might take even longer than 10 minutes to start all pods ...
    robmontalvojr
    @robmontalvojr
    @sophokles73 Thank you very much for the feedback and insights. I will experiment with these changes.
    Kai Hudalla
    @sophokles73
    On my 8 core machine it actually took close to 10 minutes to pull all images on initial deployment so you might want to increase to --timeout 15m to be safe ...
    robmontalvojr
    @robmontalvojr
    Thank you again for the insights, @sophokles73 . I did increase the time to 15m and got a different behavior this time around. It still failed, but the error seemed to be of a different type: "Error: timed out waiting for the condition". I think it would have been a bit more helpful if the error provided better guidance (instead of "...the condition").
    Kai Hudalla
    @sophokles73
    I agree. Sadly, though, we have no control over helm's error reporting quality ... ok, so the next step would be to see what has actually happened. Can you post the output of kubectl get pod -n $NS and kubectl describe node?
    robmontalvojr
    @robmontalvojr

    @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"

    Kai Hudalla
    @sophokles73
    @thjaeckle can you jump in here?
    Damián Gallo
    @damian-gallo
    Hi, i was mounting secrets into the Artemis container's filesystem when i noticed something strange. According to the 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.
    Kai Hudalla
    @sophokles73
    @damian-gallo Looks like you found a bug :-) Would you mind opening an issue at https://github.com/eclipse/packages/issues ?
    Damián Gallo
    @damian-gallo
    Absolutely! Opened at eclipse/packages#155
    Kai Hudalla
    @sophokles73
    Thanks :-)
    Thomas Jaeckle
    @thjaeckle

    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"?

    robmontalvojr
    @robmontalvojr
    @thjaeckle Thank you very much for the insights. I will keep this in mind going forward as a quick means to isolate these sort of issues. BTW, I made a few changes to the amount of resources (memory and CPU) and timeout values, and was able to get a functional environment.
    Thank you @thjaeckle @sophokles73 for helping me get past the initial hurdles.
    Damián Gallo
    @damian-gallo
    Hi, is it possible to configure the service clients of protocol adapters by editing the values.yaml file when using the deviceRegistyExample and amqpMessagingNetworkExample?
    Kai Hudalla
    @sophokles73
    @robmontalvojr would you mind sharing what kind of adjustments you made or need to make? It might be helpful to others running into similar problems ...
    Kai Hudalla
    @sophokles73
    @damian-gallo Hi Damian, you can set the adapters' client configuration using the adapters.amqpMessagingNetworkSpec, adapters.tenantSpec, adapters.deviceRegistrationSpec, adapters.credentialsSpec and adapters.deviceConnectionSpec properties in the 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.
    Damián Gallo
    @damian-gallo
    Great, thanks, I'll give it a try
    robmontalvojr
    @robmontalvojr
    @sophokles73 Kai, here it goes.. In hopes others can benefit from my mistakes... When I first started my exploration journey, I attempted to do so in a severely constrained, old hardware platform. On top of this, I took my chances by bringing up minikube with only 2vCPUs, and about 6GB memory. Because of the issues I was having on that physical platform, I decided to move the experiment to the cloud, and there I was able to get things to come up and stabilize in a few minutes. It was then I figured I needed to upgrade my box. I added memory, switched the old HDD for an SSD, and re-did my minikube cluster to match the stated requirements in the package. After effecting these changes, the environment became functional and the experience was comparable to what I had observed with my cloud environment.
    Kai Hudalla
    @sophokles73
    thanks for sharing @robmontalvojr :-)
    pravussum
    @pravussum

    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)

    Thomas Jaeckle
    @thjaeckle
    @pravussum could you provide the Ditto Protocol payload you send? I guess that in the path the addressing of inbox or outbox is missing which would deyemne
    Which would determine the direction. As this is a Ditto internal header, setting it via header mapping won't work.
    pravussum
    @pravussum
    That would be the following. I added the path attribute only because I got an error otherwise that it's missing. Since I didn't want to relate it to a specific feature/attribute, I used the "empty" path "/".
    {
      "topic": "org.anization/thething/things/live/messages",
      "headers": {
        "ditto-message-direction":"FROM"
      },
      "path": "/"
    }
    pravussum
    @pravussum

    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!

    Thomas Jaeckle
    @thjaeckle
    :+1:
    Dejan Bosanac
    @dejanb
    Hey folks, I added a passcode to the community zoom meeting so we don't have to login with eclipse credentials and manually allow people to the meeting
    Please join the meeting today with the following url https://eclipse.zoom.us/j/317801130?pwd=UGpXL29PejRrZWIzT2pKRFJGVUNqUT09
    I'll update the calendar and site later today with Frederic
    Kai Hudalla
    @sophokles73
    Thanks for the update, @dejanb :-)
    Carsten Lohmann
    @calohmn
    The new Hono chart version for the changes committed today isn't online yet. An issue has been created to resolve the corresponding CI build errors.