eclipse
Target registry option: Eclipse Hono
This pull request allows us to use Eclipse Hono as the underlying target registry.
If the Hono registry is enabled, hawkBit will fetch the list of all tenants and their respective devices during startup and whenever the user initiates a sync using the Management UI. During this synchronization process it creates all targets currently not available in hawkBit's target repository, updates the targets where necessary and deletes those which are not registered in Hono anymore. To facilitate this, the PR requests resources over Hono's REST API. Unfortunately, Hono does not offer the necessary tenant-list and device-list endpoints, yet, but there is a related PR on that front (https://github.com/eclipse/hono/pull/1418). Additionally, this PR makes use of events emitted by Hono or any derived piece of software to be as up-to-date as possible and simultaneously to avoid a pull approach which would only result in a unnecessary stream of mostly unchanged objects/states. Currently AMQP (the default) and Google Pub/Sub is supported as middlewares but since Spring Cloud Stream is used for that, it is easy to extend it to use others. For the data structures we expect from both the Hono REST API as well as the event payloads we tried to stick as close as possible to the format currently implemented in Hono respectively the one discussed in the aforementioned PR. We decided not to fully replace hawkBit's target repository since we do not want to be too heavily reliant on the Hono instance so that hawkBit still functions to a certain degree even if Hono is unreachable.
Furthermore, if the Hono registry is enabled, every device trying to authenticate must use a HonoToken instead of the usual TargetToken. hawkBit then requests the list of all credentials for that device from Hono and tries to match the provided token to one of those credentials.
In this case, we decided to have a strict dependency on the running Hono instance as we want security aspects to be as up-to-date as possible.
Additionally, we conditionally disable the target create, update and delete as all these operations should be done using Hono. This is reflected in the management UI as well.
@BrandonSchmitt it's great to see some effort being undertaken to integrate hawkbit with Hono :+1:
My understanding of your PR is that you intend to sync hawkbit's own data store with information kept in a registry that Hono uses as well. Please note the wording as well which I chose deliberately as Hono itself does not contain/own a registry but only defines APIs that it uses to retrieve necessary information from such a registry. It is true, though, that Hono comes with an example implementation of such a registry which implements the relevent APIs. However, this registry is not suitable for production environments. I also understand that you intend to use the HTTP based Management API defined by Hono in order to sync the data. This makes a lot of sense when assuming that any registry used with Hono will also implement this API. Be aware, though, that from Hono's perspective that is not mandatory as Hono's protocol adapters only depend on the Tenant, Device Registration, Credentials and Device Connection APIs but not the Management API. This makes sense because from Hono's perspective, it is not relevant how the data got into the registry but only that it is there and can be retrieved using the APIs mentioned above. That said, I agree that the Mangement API is (currently) your best option in order to keep your dependency on Hono at a minimum. However, I am not sure if extending the Management API with resources specifically for supporting the synchronization use case you have in mind is the right approach to the problem. In fact, it might make more sense in a real world use case to have a single registry/data store which keeps all the data necessary in on persistent layer and which implements all APIs required by Hono and hawkbit natively.
I am interested in your thoughts about this as we are having similar discussions around integration of Ditto with Hono as well.
Cheers, Kai
Thanks a lot @sophokles73 for sharing your thoughts on this from the Eclipse Hono project. I totally agree that it would make a lot of sense to use the same registry/data store for an integration (e.g. Ditto) in the log run. But I'm afraid that's easier said than done.
@BrandonSchmitt what do you think?
Thank you for your insight, @sophokles73 and @schabdo, and please excuse my late response.
We have implemented such a custom device registry which provides the REST and AMQP endpoints defined by Hono and the additional endpoints we considered necessary to synchronize hawkBit as described above.
We aim to open source that project, preferably under the Eclipse IoT banner. Unfortunately, our device registry implementation still has some dependencies which themselves are not open source, yet.
We recently discussed this PR internally and came up with the idea to at first extract the Management API out of Hono into a third project, say the Device Registry project. It would further define all the APIs, resp. endpoints, needed by both Hono and hawkBit. As soon as we have made our implementation ready for open source, we would provide our current device registry as a reference implementation or a starting point or the like. Of course it may be further extended to cover other Eclipse projects (e.g. Ditto) in the future.
What are your thoughts about this and what additional steps would you deem necessary for us to add our device registry to the Eclipse IoT project?
We recently discussed this PR internally and came up with the idea to at first extract the Management API out of Hono into a third project, say the Device Registry project. It would further define all the APIs, resp. endpoints, needed by both Hono and hawkBit.
I am not sure if I understand correctly. Are you suggesting to move Hono's Registry Management API into a separate project? Can you give an example of all the APIs ... needed by both Hono and hawkBit? Are you referring to Hono's Tenant, Device Registration APIs etc?
Never mind the delay. Maybe it's easier to follow if you share a rough picture depicting your idea
Well, in a way, I was referring to this:
In fact, it might make more sense in a real world use case to have a single registry/data store which keeps all the data necessary in on persistent layer and which implements all APIs required by Hono and hawkbit natively.
The idea is as simple as cited above (even though that does obviously not mean it's as easily implemented): Create a device registry which functions as the data source for Hono and hawkBit. Which APIs exactly have to be offered by this registry is a question I cannot fully answer right now as I suppose that you have more insight on what is needed and what not and in which direction you want to head with these and/or other Eclipse projects in the future.
My first thoughts on APIs the considered device registry should offer:
- Tenant Management
- Target/Device Management
- Credential Management
Maybe REST with list, read, create, update, delete endpoints could suffice?
Hmmm, just to get this straight. In this setup, how do devices connect to hawkbit, via Hono or using hawkBit's DDI?
They would connect to hawkBit the same way as it is now: using the hawkBit DDI.
If we continued with the aforementioned idea of a new, separate device registry then there would be no need to make hawkBit and hono directly interoperable, I suppose. They both simply needed to fetch their device/target data from this registry.
@BrandonSchmitt Please resolve merge conflicts.
So maybe it can be merged together with https://github.com/eclipse/packages/pull/18
@sophokles73 do you need anything else from us to get this merged? currently we have to maintain a fork of hawkbit which is not ideal for us.
Well, at least I'm a good starting point :) I haven't followed along the whole discussion around this topic. Last thing I'm aware of is that it was subject of a community call in the context of the Eclipse IoT Packages project in which @laverman is involved as well. So I guess he knows better than I do.
@laverman any thoughts on this?
do you need anything else from us to get this merged?
If you ask for my opinion on this "we" should have/start a discussion about a few things:
- As of my understanding Hono's device registry is not intended for production use [1]. How we deal with that?
- Integration with Hono (incl. dependencies) should be optional and rather become part of HawkBit's extensions
- As stated above: Maybe leverage Ditto as common device registry (cf. https://github.com/eclipse/hawkbit/issues/796)
- Is there any overlap/stake of the IoT packages project in here (I simply don't know)
[1] https://www.eclipse.org/hono/docs/user-guide/device-registry
Looks like upcoming Hono release 1.3.0 already tackle the mentioned device registry issue (cf. Release Notes)
There would still be a problem even if all of your bullet points were resolved: this PR builds upon two endpoints which do not yet exist in Hono: One for retrieving all tenants and one for retrieving all devices of a tenant. There is a PR laying the groundwork for that (as mentioned in my post) but there seems to be some reservation about adding an ID field to the returned entities which is necessary for this hawkbit PR (or for such list endpoints in general IMO).
- Integration with Hono (incl. dependencies) should be optional and rather become part of HawkBit's extensions
That's reasonable and I have no problem transforming this PR into a PR against the extension repository.
- As stated above: Maybe leverage Ditto as common device registry (cf. #796)
I have briefly dived into the Ditto documentation and I can see it to be a good fit as a device registry. It provides a thing list endpoint which could work as the device list. Ditto seems to not support multi tenancy but this could be leveraged by e.g. thing attributes.
- Is there any overlap/stake of the IoT packages project in here (I simply don't know)
I am not sure that I understand this point correctly. If you are posing the question whether there is any overlap of features/dependencies in the different Eclipse IoT projects: a device/thing/gateway registry is needed by at least HawkBit, Hono and Ditto. Other than that I don't know.
Do you have any news on the device registry aspect and/or have you discussed the question of overlap internally?
@BrandonSchmitt
speaking on behalf of Eclipse Hono, here are a few remarks.
Hono 1.3.0 contains a Mongo DB based implementation of the device registry. This registry still uses its own collections, though, i..e we do not access collections maintained by Ditto. PR https://github.com/eclipse/hono/pull/1995 deals with adding an operation for retrieving devices of a (single) tenant in Hono's Registry Management API. Once this operation is available, hawkBit could use it to sync devices. A similar operation could be added to the tenants endpoint.
There is a PR laying the groundwork for that (as mentioned in my post) but there seems to be some reservation about adding an ID field to the returned entities which is necessary for this hawkbit PR (or for such list endpoints in general IMO).
I believe you are referring to https://github.com/eclipse/hono/pull/1418 and for the devices part, we will have the device IDs in the new response to the search devices operation. So I guess we are on the same page here.
Using Ditto as a replacement for hawkBits own registry certainly makes a lot of sense to me. Ditto does have a concept similar to a tenant which is called namespace. In the IoT Packages project we already use this to align the tenant/deviceId from Iot Hub with the namespace/thingID in Ditto. This is just a convention but it works correctly. So I guess the same (or similar) approach could be used when integrating hawkBit with Ditto for the purpose of storing all data relevant to hawkBit in Ditto. If I am not mistaken, the hawkBit team is already working on such an integration. Maybe @schabdo can comment on this?
Sorry, it took a while to catch-up with all the ongoing stuff after a long summer vacation. I still hope to get support from @laverman in this topic as he is the project lead.
[...] have you discussed the question of overlap internally?
I recently learned that I was wrong with my assumption that the Packages project is all about integration. Hence integration glue code rather belongs there. However "Projects are encouraged to integrate as much functionality as possible into their own code base" [1]. So there seems to be no overlap here.
So I guess the same (or similar) approach could be used when integrating hawkBit with Ditto
I totally agree. Thanks @sophokles73 for sharing your thoughts on this. Highly appreciated!
If I am not mistaken, the hawkBit team is already working on such an integration
I talked to a bunch of people over here and indeed there is some ongoing "background" work to provide integration with Ditto. However there is no commitment for a timeline. So I don't expect to see this happen soon. Having this said I think we have two options how to proceed:
- You wait for the Ditto integration to show up
- We proceed with the direct Hono integration as hawkBit extension (if feasible)
If you integrate with Ditto and go down the path @sophokles73 mentioned in order to connect Hono with Ditto I see a risk that this effort might become obsolete due to the mentioned activities. Option 2 on the other hand would allow the community to have a choice between hawkbit -> Hono and hawkBit -> Ditto -> Hono (maintenance work aside).
What do you guys think?
[1] https://www.eclipse.org/packages/about
I have to admit that I am getting a little confused by all the options and different approaches that have been discussed as part of this PR. My understanding is that this PR aims at providing a way to sync hawkBit's own data store with tenant and device registration information retrieved from a data store via the Device Registry Management API defined by the Hono project. Depending on the underlying implementation of that API and the number of tenants/devices registered, this may or may not be a viable option for production scenarios. In order to make this happen, and thus make this PR workable, Hono's Device Registry Management API would need to be extended with an operation to retrieve all tenants, if I am not mistaken. FMPOV the Hono community would not object such a feature.
The other options brought up in this PR are also relevant and worth elaborating but should probably be discussed in separate issues/PRs in order to allow this PR to come to a conclusion.
There is currently a JDBC based implementation of Hono's device registry being added to the Hono project. Maybe this could serve as the basis for a combined data store that is used by both hawkBit and Hono to keep their respective data.
In order to make this happen, and thus make this PR workable, Hono's Device Registry Management API would need to be extended with an operation to retrieve all tenants, if I am not mistaken. FMPOV the Hono community would not object such a feature.
Hono already offers support to retrieve all the registered devices. I think its good to extend the Device Registry Management API also to retrieve all registered tenants. I have created an issue eclipse/hono#2239 for that in Hono repository. Any PR contributions for this feature are welcome.
Hono already offers support to retrieve all the registered devices. I think its good to extend the Device Registry Management API also to retrieve all registered tenants. I have created an issue eclipse/hono#2239 for that in Hono repository. Any PR contributions for this feature are welcome.
I would like to update regarding the above feature request in Hono. With the recent release of Hono 1.6.0, now the the Device Registry Management API supports retrieving the registered tenants with optional filters, paging and sorting options. The MongoDB based device registry in Hono supports this feature.
@BrandonSchmitt, @schabdo With the above mentioned added features for getting tenants and devices in the Hono MongoDB device registry, is there a chance to go forward with this PR and the idea of syncing hawkBit and Hono information? Or would aiming for usage of the Hono JDBC Device Registry (now available for some time already) as a basis for a combined data store for both hawkBit and Hono (as mentioned above) be a better way?
