New proposal for MQTT Discovery Handler #80
Conversation
diconico07
requested review from
kate-goldenring,
bfjelds,
romoh,
jiria,
edrickwong and
johnsonshih
as code owners
This is a new proposal for an MQTT Discovery Handler, this proposal tries to keep things as simple as possible while still solving most use cases This is part of project-akri/akri#106 Signed-off-by: Nicolas Belouin <[email protected]>
diconico07
force-pushed
the
mqtt-dh-proposal
branch
from
50c829d
to
955009f
Compare
|
I created a reference implementation of a Discovery Handler for this proposal, you can find it at suse-edge/akri-mqtt-discovery-handler. |
|
I took a quick look at all previous discussions regarding this topic and the new proposal. Based on my knowledge, as I work with sub-components of cutting and welding machines that use MQTT, the new proposal from @diconico07 is precise to discover the MQTT-supported devices/machines in the shopfloor backed by a common external MQTT broker running on a centralized location, for eg, on a factory server and also to advertise the discovered device resources to Kubernetes based consumer applications. One thing to note is that the MQTT Discovery Handler doesn't need to run on every node of the cluster. It is only relevant for something like UDEV device discovery. Every MQTT Discovery Handler is a client of the same MQTT broker in the network. It is better to have a cluster-wide Discovery Handler for this use case. |
I do not completely agree on this, while in theory you can, you may not want to, as if you lose connection between a node or set of nodes and the MQTT broker, then having a DH per node ensures the workload will be on the working nodes. Moreover, the current agent architecture doesn't allow to have remote/centralized discovery handlers. |
|
I agree with you. Few more tricky but possible scenarios are,
|
|
|
||
| ## Instance properties | ||
|
|
||
| The ID of the device is the full topic used by the device. |
There was a problem hiding this comment.
what if a device publishes multiple topics? Do we create multiple instances for it?
There was a problem hiding this comment.
Yes, the base idea here is to craft the query to only match a channel per device
| timeoutSeconds: | ||
| type: int64 | ||
| minimum: 0 | ||
| exclusiveMinimum: true |
There was a problem hiding this comment.
What does exclusiveMinimum mean?
There was a problem hiding this comment.
It means that 0 is not a valid value
| type: string | ||
| timeoutSeconds: | ||
| type: int64 | ||
| minimum: 0 |
There was a problem hiding this comment.
I'm assuming "no timeout" is max i64?
There was a problem hiding this comment.
"No timeout" makes no sense to me here as it would be that a device can never disappear/goes down
| Because of these properties, it is impossible to discover devices that do not publish any message. | ||
|
|
||
| Usually a device will publish into topics that are specific to that device instance so that it becomes possible to know the origin of the message. | ||
| For example a weather station might publish into topics like `weather/<city>/temperature` and `weather/<city>/pressure` with `<city>` the location of station. |
There was a problem hiding this comment.
Wanted to point out a coAP discovery handler that was worked on awhile ago as that protocol has topics and might provide some more inspiration. Proposal is coap.md in the closed pr: https://github.com/project-akri/akri/pull/346/files#diff-0c3abadcc72d01ab2b22fd1f4a2e696f0f3c350909e2d991cf7fea22a4311789
| @@ -0,0 +1,83 @@ | |||
| # [MQTT](https://mqtt.org/) Discovery Handler | |||
|
|
|||
There was a problem hiding this comment.
Can we add a section on how the Akri broker will use the information provided? If i understand MQTT well enough, doesn't the Akri broker essentially just subscribe to the same MQTT broker as the Akri DH. To me, this makes "discovery" hard to understand, potentially similar to OPC with Akri. Might be worth adding a section that talks about how this is still useful.
There was a problem hiding this comment.
The Akri broker would indeed connect to the same MQTT broker.
It might however subscribe to different topics: for the pressure+temperature example, you could do discovery on temperature (so DH subscribe to weather/+/temperature) and have the Akri broker subscribe to all topics of the discovered instance (so subscribe to weather/paris/# for example).
The Akri broker would use the information provided to identify the topics to operate on and really identify the device, as the way the topics are crafted is not standardized, we can't infer a proper device identifier from it, so we just give the whole information, and let the Akri broker know better about what is the device identifier in the topic name.
About why this is needed, see a complex machine for example, you can spawn an application only able to handle one of them at a time and thus spawn it dynamically for every such machine plugged to your MQTT broker, this way you have the same overall configuration whether you have one machine or ten machines.
Similarly, as a manufacturer I could provide a standard set of Akri Configuration to spawn the needed user facing apps depending on what exact model or set of options you as an end-user enabled (so basically if machine talks to topic /mymachine/extension/X then spawn a pod that handles this specific extension, but if not then extension not enable and the pod is not needed).
I'm not sure this is really different from how the other DH are used 🤔
|
@shantanoo-desai copying you here in case you have any thoughts given you've been thinking about Akri + MQTT for awhile |
This is a new proposal for an MQTT Discovery Handler, this proposal tries to keep things as simple as possible while still solving most use cases
This is part of project-akri/akri#106