docs: add MQTT Proposal Draft v0.1.0 #341
Conversation
- Add detailed description of possible Integration of Akri and MQTT - Add diagrams for different descriptions
shantanoo-desai
requested review from
bfjelds,
Britel,
jiria,
kate-goldenring and
romoh
as code owners
There was a problem hiding this comment.
Thank you for this awesome work! The background and diagrams are really helpful. My main questions that i think could be fleshed out in the proposal are:
What resources should Akri advertise?
Why is this an important scenario? As you pose in the question section, is this only useful on the Edge?
What does discovery look like? Network scan for MQTT brokers?
What language do you think you would implement the discovery handler in?
| Depending on the IoT Device's availability the application pertaining to the data such a device produces | ||
| can be scaled accordingly. | ||
|
|
||
| ## What can Akri solve? |
There was a problem hiding this comment.
Should this be narrowed based on the discovery strategy. For example, Akri + MQTT Broker discovery makes it so an operator can say, run this client (Akri "broker") on nodes that can see an MQTT Broker with x,y, and z topics. How do MQTT clients normally respond to topics no longer being published (devices going away)? It seems like with this implementation, if a topic goes away that a client/akri broker was using, Akri would automatically bring down the client. Is that ideal?
There was a problem hiding this comment.
How do MQTT clients normally respond to topics no longer being published (devices going away)?
There is a possibility of maintaining the connection session between the akri broker (containing mqtt client) however to my knowledge there is no mechanism in MQTT that provides a graceful disconnection if there is no data being published on the subscribed topics. I have to the check the MQTTv5 Specifications where they provide Session Expiry and Message Expiry.
The Session Expiry feature might be able to trigger a graceful disconnection, which in turn leads to bringing down the Akri broker in a much more dynamic manner.
|  | ||
|
|
||
|
|
||
| ## Questions |
There was a problem hiding this comment.
To add to the questions, for each device Akri discovers, a kubernetes resource and an Akri Instance are made. For example, for udev with a filtering rule to only find usb cameras, a resource and Instance would be created for each instance. Then Pods can request these resources. Akri automates the deployment of Pods ("brokers") requesting the resources. What would be a kubernetes resource? (1) each discovered MQTT broker (2) each topic of each MQTT broker (3) MQTT broker with a set of topics (4) something else? How do we make it so a Pod can request the resource(s) that represent "a MQTT broker with a thermometer topic"?
|
|
||
| - Is gRPC Server required within the MQTT Monitoring Broker? Does the Publish/Subscribe mechanism require a different technology? | ||
|
|
||
| - How actually would Discovery Handler Look like? When one talks about Discovery Handler, is this pertaining to only MQTT Broker Server or the discovery of leaf |
There was a problem hiding this comment.
It seems like this should have its own section in the proposal with the following question also seeming to fit in a "What does discovery mean?" section. From previous discussions, it seems like Akri's role is discovering MQTT Broker Servers.
| discoveryDetails: | ||
| name: mqtt | ||
| discoveryDetails: |+ | ||
| serverUrls: |
There was a problem hiding this comment.
What are the server urls? The urls to the MQTT brokers? Is there a way to discover them without being given their addresses? If you are modeling after OPC UA, the server urls can be explicitly provided but ideally that implementation will be expanded to do a network scan instead. Is something like that possible for MQTT?
There was a problem hiding this comment.
There is no implementation MQTT Broker discovery. The only possible way to achieve this is AFAIK is through Zeroconf/mDNS/DNS-SD Solution. Possible scan on standard ports like 1883 or 8883 might yield results of possible MQTT Brokers on Edge devices however this is not standard practice.
There is however an alternative Protocol called MQTT for Sensor Networks aka. MQTT-SN which is an OASIS Standard which tackles the issue of making MQTT-SN more compatible for Low Power Devices in Lossy Networks that do not necessarily use TCP/IP Stack e.g. ZigBee, Bluetooth, LoRa etc. and provides a Gateway Discovery / Advertisement.
|
It would help me to see some of the Akri concepts identified explicitly. For example, how does the MQTT Monitoring Broker or MQTT Custom Application relate to Akri's Discovery Handler or Broker concepts (is it one or the other or both)? I'd also like a section to identify what existing challenge an Akri-MQTT solution would make easier. For example, I could imagine a couple:
|
|
PR has been automatically marked as stale due to inactivity for 45 days. Update the PR to remove label, otherwise it will be automatically closed." |
|
@kate-goldenring @bfjelds Closing this PR at the moment since I am stuck with some work and will come back to it once I dedicate some time for Akri. If there are some members willing to take this topic, I would gladly assist |
@shantanoo-desai sounds good. Thanks for the update! |
of Akri and MQTT
What this PR does / why we need it:
This PR introduces an initial draft to integrate MQTT Protocol to Akri.
Since there is already a discussion thread for Support of MQTT (see #106 ), this proposal builds upon the discussion and helps
provide a more detailed description of the protocol under question (MQTT) and how a possible integration might look like.
This documentation is written while considering some already provided proposals under the
docs/proposalsdirectory.It contains some questions pertaining to implementation as well as integration aspects of MQTT with Akri.
This proposal is bound to be edited and changed based on discussions/feedback/criticisms.
Special notes for your reviewer:
This PR should not break any existing Test Pipelines.
If applicable:
cargo fmt)cargo build)cargo clippy)cargo test)cargo doc)./version.sh)