Export tedge features via a library crate #2014
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: James Rhodes <jarhodes314@gmail.com>
jarhodes314
had a problem deploying
to
Test Pull Request
GitHub Actions
Failure
Signed-off-by: James Rhodes <jarhodes314@gmail.com>
jarhodes314
force-pushed
the
feat/tedge-lib
branch
from
ab63d49
to
3a026ca
Compare
jarhodes314
temporarily deployed
to
Test Pull Request
GitHub Actions
Inactive
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #2014 +/- ##
==========================================
+ Coverage 72.59% 72.86% +0.27%
==========================================
Files 279 281 +2
Lines 30630 30518 -112
Branches 30630 30518 -112
==========================================
+ Hits 22236 22238 +2
+ Misses 6796 6655 -141
- Partials 1598 1625 +27
☔ View full report in Codecov by Sentry. |
Robot Results
Passed Tests
|
Comment on lines
76
to
82
| Ok(Event::Incoming(Incoming::PubComp(rumqttc::PubComp { pkid: 2 }))) => { | ||
| publish_device_create_message( | ||
| &mut client, | ||
| &bridge_config.remote_clientid.clone(), | ||
| device_type, | ||
| )?; | ||
| } |
There was a problem hiding this comment.
So this is "to speed up the connection (sending a device creation message as soon as the first one is acknowledged, previously we waited for a heartbeat message)".
Okay. But why as reaction to message numbered 2 ?
- Is this the message sent on
Ok(Event::Incoming(Packet::SubAck(_))) - or sent on
Ok(Event::Outgoing(Outgoing::PingReq)).
This is also relies on the fact that publish_device_create_message send the message with QoS::ExactlyOnce (this is actually the case).
So this is okay but a bit fragile. So I would consider:
- to add some comments
- to react independently of the pkid (as we only send creation message on this connection)
- to react also on
PubAck.
I would even consider to send the message with QoS AtLeastOnce as we are now blindly re-sending the message if c8y is not fast enough.
There was a problem hiding this comment.
It's using pkid: 2 as that is the first PubComp we receive (corresponding to the message we sent after receiving SubAck), and I was trying to avoid this code triggering itself as we should need to send exactly two messages to get Cumulocity to reply to say the device already exists.
There was a problem hiding this comment.
I was trying to avoid this code triggering itself as we should need to send exactly two messages to get Cumulocity to reply to say the device already exists.
You can discuss this with @rina23q as she already tried different approaches for that purpose.
You can also discuss this with @reubenmiller as he might shed a new light to this issue.
jarhodes314
temporarily deployed
to
Test Pull Request
GitHub Actions
Inactive
jarhodes314
temporarily deployed
to
Test Pull Request
GitHub Actions
Inactive
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Proposed changes
In order to enable thick-edge remote connectivity, we would like to connect thin-edge to Cumulocity programmatically, and we would like to do this without going via the tedge binary, as that makes error handling more tricky (than calling a Rust function), and it means we are forced into running logic that doesn't make sense in Kubernetes, such as ensuring mosquitto is connected when we run
tedge connect c8y(mosquitto is run in a separate container, and is only started after we have connected the device).This PR modifies the tedge crate to be a library crate, which allows other crates to import functions from
tedge. I have exported the direct connection logic so our code can call that directly, and tweakedmain.rsto import from the library. I have also added a case to the direct connection function to speed up the connection (sending a device creation message as soon as the first one is acknowledged, previously we waited for a heartbeat message). That speeds up function from around 5/10s to more like 1s (I haven't measured it in detail, but it's noticeably faster.Types of changes
Paste Link to the issue
Checklist
cargo fmtas mentioned in CODING_GUIDELINEScargo clippyas mentioned in CODING_GUIDELINESFurther comments