Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 07:10

    sophokles73 on master

    Do not close DAO twice Signed-… (compare)

  • 07:09

    sophokles73 on 1.10.x

    Do not close DAO twice Signed-… (compare)

  • 07:03
    sophokles73 labeled #3030
  • 07:03
    sophokles73 labeled #3030
  • 07:03
    sophokles73 commented #3030
  • 07:01
    sophokles73 milestoned #3029
  • 07:01
    sophokles73 labeled #3029
  • 07:01
    sophokles73 labeled #3029
  • 07:01
    sophokles73 commented #3029
  • 07:00
    sophokles73 assigned #3031
  • 07:00
    sophokles73 labeled #3031
  • 07:00
    sophokles73 unlabeled #3031
  • 06:59
    sophokles73 milestoned #3031
  • 06:59
    sophokles73 labeled #3031
  • 06:59
    sophokles73 labeled #3031
  • Jan 15 15:25
    HusoBey21 starred eclipse/hono
  • Jan 15 14:25
    BobClaerhout edited #3029
  • Jan 15 14:25
    BobClaerhout edited #3030
  • Jan 15 14:24
    BobClaerhout edited #3030
  • Jan 15 14:24
    BobClaerhout opened #3031
Kai Hudalla
@sophokles73
@/all I would like to do the 1.10.0 release this week. Anything else you need to go into it in addition to what we already have on the project board?
2 replies
samrose
@samrose
Is it feasible to use hono outside of kubernetes? It seems so, but I wondered what knowledgeable people here think
Abel Büchner-Mihaljević
@b-abel
@samrose It is possible. There used to be deployment scripts for Docker Swarm, but they were removed a long time ago. The deployment of the sandbox VM was still running on Docker Swarm until recently. That can still be found in the Git history for inspiration: https://github.com/eclipse/hono/tree/5505c3c6f6d4cb2ba70828188c9e38af2d02f1de/deploy/src/main/sandbox
samrose
@samrose
@b-abel I was considering running this with nomad, consul cluster
thank you!
Kai Hudalla
@sophokles73
@/all I will now start the 1.10.0 release build ...
Kai Hudalla
@sophokles73
@/all Our PGP key used for creating signatures of our release artifacts has expired. I have created an issue with Eclipse webmasters to extend the key's validity. Until then we cannot publish the artifacts to Maven Central ...
Kai Hudalla
@sophokles73
@/all The 1.10.0 release build has succeeded and I have pushed the container images to Docker Hub. However, the artifacts still cannot be published to Maven Central but that shouldn't be a big issue as most people install using the container images anyway ...
Bob Claerhout
@BobClaerhout
Hi, I was trying to run the quarkus images just now (version 1.10.0) and I stumbled upon a change in the lora adapter. In the spring lora adapter I'm not obliged to confugre following property: hono.lora.commandEnabledTenants. I was wondering why this is required in the quarkus version?
As you might imagin, I would not like to change my deploy because I'm adding a new tenant. Why can't the lora adpater look at the gateways with a commandEndpoint and add those dynamically to the used tenants?
Kai Hudalla
@sophokles73
This is probably a bug in the LoraProtocolAdapterOptions configuration class where the corresponding property is not optional. Anyway, it looks like LoraProtocolAdapterProperties.getCommandEnabledTenants() is never used anywhere in the Lora adapter so I guess we can simply remove the configuration property altogether.
Kai Hudalla
@sophokles73
@BobClaerhout can you create an issue and a corresponding PR?
Bob Claerhout
@BobClaerhout
Kai Hudalla
@sophokles73
@/all I would like to start planning for Hono 2.0.0. Most imminent questions FMPOV are: 1) release time frame and 2) breaking changes.
Personally, I would like to see the 2.0.0 release by end of Q1 2022. At a minimum I would like to remove the already deprecated components/modules like the client module, the Device Connection service, the File based registry and the Spring Boot based variants of the components. However, we should also take the opportunity to introduce other breaking changes to existing external APIs that we consider helpful/necessary. Thoughts?
Oh, and I think we should remove support for Java 8 from the core module and upgrade to Java 17 code level.
Kai Hudalla
@sophokles73
@b-abel There are currently four PRs addressing #2837 and it is kind of hard to keep track. Are they all still relevant/required or can you maybe close some of them?
2 replies
Bob Claerhout
@BobClaerhout
Hi all, as you know we are installing our IoT solution on customers private clouds. This means we also would like to rely on the managed kafka cluster from the customer. However, this means we won't always have access to create topics (which used by the adapter for the internal topics). My understandig is that it is currently not possible to provide the used topics for internal commands. Is this correct? If so, might it be an idea to provide these topics somehow so the customer can manually create the topics and we do not need the permission to create them automatically? WDYT?
Kai Hudalla
@sophokles73
The problem is that the names of these topics are specific to the protocol adapter instance and are therefore determined dynamically during runtime, taking into account the name of the container that the adapter is running in. @calohmn any idea how to address this?
Carsten Lohmann
@calohmn
I think this is a valid point to bring up. I had thought about different alternatives to these dynamic topic names already, but all had their challenges. @BobClaerhout I think it would be best if you could create a Github issue for this. Then we can develop ideas there.
Bob Claerhout
@BobClaerhout
sure, I'll create one. A first step in the right direction might be to configure it but when you do, you can't have multiple adapters of the same type, since that would cause these both adapters to be reading the same topic. Anyway, I'll create an issue
Abel Büchner-Mihaljević
@b-abel
Wasn't it once discussed in a community call that we also want to offer (via configuration) the possibility that all protocol adapters receive commands via a single topic. Or do I remember that wrong?
Bob Claerhout
@BobClaerhout
Kai Hudalla
@sophokles73
@b-abel That was indeed one of the discussed options, in particular for use cases where you do not expect that many commands to be sent and therefore can afford to simply ignore the commands in adapter instances that the target device is not connected to. However, IIRC we decided to start with implementing the more general approach that we now have. Maybe you can add a pointer to the original issue in #2920 ?
Abel Büchner-Mihaljević
@b-abel
Kai Hudalla
@sophokles73
@b-abel exactly
Simon Mayer
@pragmayticer
Hi guys I'm a college of @JulianFeinauer . We use hono for device registration and other admin issues. I have a question about the topics. Can I subscribe to every topic e.g(myHouse or machine/4711) or just these three(command,telemetry and event) ?
Abel Büchner-Mihaljević
@b-abel
Hi @pragmayticer! Are you referring to MQTT topics or Kafka topics? And are you thinking about the device side or the northbound business application?
Simon Mayer
@pragmayticer
MQTT/ AMQP Topics. Well both sides. I want my own topics, first to subscribe on the northbound business application and the device should logically send to my custom topics......
Abel Büchner-Mihaljević
@b-abel
This is not supported. Hono uses the fixed topic names and AMQP addresses that are part of its API. If you want to use different MQTT topics, you could use a Protocol Gateway. You'll find a template for an MQTT Protocol Gateway in https://github.com/eclipse/hono-extras/tree/master/protocol-gateway/mqtt-protocol-gateway-template
Simon Mayer
@pragmayticer
ah okay, Thank you!
Julian
@JulianFeinauer
Thanks @b-abel! @pragmayticer we have to distinguish the messages by subject or on the payload level
Kai Hudalla
@sophokles73
With MQTT you can also use a property bag that you append to the topic name as outlined here. This way, you can for example include a content-type that you can then use for message routing in your downstream application. With AMQP 1.0 it is easier as it natively supports message properties (including content-type and other standard properties).
Kai Hudalla
@sophokles73
@JulianFeinauer Hi Julian, have you seen the new Eclipse Kanto project proposal? Given your interest in ioFog in the past, I wonder if this might be of interest to you as well? Let me know if you would like to know more about it. I can then get you in touch with the project lead ...
Bob Claerhout
@BobClaerhout
Goodmorning all, I'm running into an issue with the kerlink lora adapter. It looks like the implementation in hono doesn't comply with the kerlink version (anymore) used by our customers (a newer one, don't know exactly which one but content-type is different and payload has another structure as well). It was added in '19 and it doesn't like anyone has made any functional changes to this provider.
How do we cope with this? Do I create a new provider which includes a version somewhere or do I just update this provider according to the message I'm receiving now?
Besides this example with kerlink I'm expecting these issues to be popping up in the future for other providers as well so I think we should carefully think about this. For that, my preference goes to adding a version in the path somewhere. WDYT?
Kai Hudalla
@sophokles73
@BobClaerhout If the content-type is different then you could also handle/parse the incoming message differently based on the content-type only, i.e. without the need for introducing new endpoint URIs.
Bob Claerhout
@BobClaerhout
That's a good idea. It will, however, require some changes in the structure of the adapter as well since it currently only expectes 1 content type and add routes based on the path
Kai Hudalla
@sophokles73
I am not 100% sure but I guess you can also add routes for a combination of path and content-type and register different handlers for them.
Bob Claerhout
@BobClaerhout

I just tried running the lora quarkus adapter in combination with kafka and I ran into following misconfiguration exception:

MessagingClientProviders.MessagingClientProviders
        if (!telemetrySenderProvider.containsImplementations()) {
            throw new IllegalArgumentException("at least one TelemetrySender implementation must be set");
        }

Is the kafkaconfiguration different in the quarkus container compared to the spring one?

When I look at the secret, I'm seeing following configuration:

hono:
  kafka:
    defaultClientIdPrefix: adapter-lora-vertx
    commonClientConfig:
      bootstrap.servers: <bootstrap>:9092
      sasl.jaas.config: org.apache.kafka.common.security.scram.ScramLoginModule required
        username="<username>" password="<password>";
      sasl.mechanism: SCRAM-SHA-512
      security.protocol: SASL_PLAINTEXT

This configuration just works for the spring container but doesn't seem to work with the quarkus container. Anyone experiencing the same things?

Bob Claerhout
@BobClaerhout
Ah, it looks like other configuration changes are required aside from just using the quarkus image. Can somebody confirm this?
Abel Büchner-Mihaljević
@b-abel
@BobClaerhout I have not tried this lately but there has been some refactoring lately. It would be great if you could report any bugs or inconsistencies you encounter.
Which Hono version do you use?
Bob Claerhout
@BobClaerhout
Hi @b-abel , thanks for you response, I didn't have the time yet to fully convert from the spring images to the quarkus ones.
Following happened: I updated the kerlink adapter to support the new kerlink format (eclipse/hono#2937). I was building the image myself and thought: ah, why not try the quarkus one. I configured the lora adapter to use the quarkus image but this wasn't working (didn't do any change besides that one... I think that was my mistake).
I build the spring image and that image just works properly.
Both images are build from the latest master while the rest of the images are still using 1.10.0
Kai Hudalla
@sophokles73
Does the Lora provider actually start up using your custom built Quarkus based image? If so, I assume that it fails during start up with some error message(s) in the log? If so, can you post the output?
Bob Claerhout
@BobClaerhout
No, it doesn't startup. I'm getting following exception immediatly: 2021-11-15 08:26:04,529 ERROR [io.qua.run.Application] (main) Failed to start application (with profile prod): java.lang.IllegalArgumentException: at least one TelemetrySender implementation must be set. But I saw the quarkus images need slightly different configuration as well so I think the test doesn't tell us anything. I'll try running the quarkus images again later with all hono configuration (in the helm chart) set to quakus as well compared to only changing the image.
Kai Hudalla
@sophokles73
Actually, I am not aware of any additional config properties required when using the Quarkus images instead of the Spring Boot based images.
But we are not doing any integration tests with the Lora adapter. So I am not 1005 sure if this should indeed work.
Bob Claerhout
@BobClaerhout
ok, I'll test it once again and let you know if it succeeded
Carsten Lohmann
@calohmn
@BobClaerhout I couldn't reproduce the lora adapter issue, testing with current Hono master (I had to remove the "hono.kafka.defaultClientIdPrefix" property - see eclipse/hono#2960). The error you mentioned is raised when the "bootstrap.servers" property isn't defined or empty. I don't see an issue with your config above, but anyway, maybe you can try setting the value in quotes?
Bob Claerhout
@BobClaerhout
@calohmn , thanks for looking into this and your patience. I tried again just now and I encounter following exception when running the lora adapter:
io.smallrye.config.ConfigValidationException: Configuration validation failed:
        hono.kafka.defaultClientIdPrefix does not map to any root
        at io.smallrye.config.ConfigMappingProvider.mapConfiguration(ConfigMappingProvider.java:855)
        at io.smallrye.config.ConfigMappingProvider.mapConfiguration(ConfigMappingProvider.java:811)
        at io.smallrye.config.SmallRyeConfigBuilder.build(SmallRyeConfigBuilder.java:403)
        at io.quarkus.runtime.generated.Config.readConfig(Config.zig:1222)
        at io.quarkus.deployment.steps.RuntimeConfigSetup.deploy(RuntimeConfigSetup.zig:42)
        at io.quarkus.runner.ApplicationImpl.doStart(ApplicationImpl.zig:326)
        at io.quarkus.runtime.Application.start(Application.java:101)
        at io.quarkus.runtime.ApplicationLifecycleManager.run(ApplicationLifecycleManager.java:105)
        at io.quarkus.runtime.Quarkus.run(Quarkus.java:66)
        at io.quarkus.runtime.Quarkus.run(Quarkus.java:42)
        at io.quarkus.runtime.Quarkus.run(Quarkus.java:119)
        at io.quarkus.runner.GeneratedMain.main(GeneratedMain.zig:29)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:568)
        at io.quarkus.bootstrap.runner.QuarkusEntryPoint.doRun(QuarkusEntryPoint.java:48)
        at io.quarkus.bootstrap.runner.QuarkusEntryPoint.main(QuarkusEntryPoint.java:25)
All other services run just fine in quarkus