-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add mqtt.topic_root
and mqtt.device_topic_id
options
#2231
Conversation
@@ -38,22 +40,35 @@ pub struct AgentConfig { | |||
pub use_lock: bool, | |||
pub log_dir: Utf8PathBuf, | |||
pub data_dir: Utf8PathBuf, | |||
pub mqtt_device_topic_id: Arc<str>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using Arc<str>
here because it's better for immutable data, as it doesn't allocate more memory when cloning, and also tells the reader that it's immutable. More information in this video.
I think most of the data we're working with in thin-edge is immutable, so I'm experimenting with using these immutable types for new code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you. Indeed a nice hint, that can be used for all the String
s we use as names or identifiers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is really nice! It's a great help to distinguish if a member is immutable or mutable by just looking at the struct data type.
} | ||
|
||
impl AgentConfig { | ||
pub fn from_tedge_config( | ||
pub fn from_config_and_cliopts( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should try to find a more systematic solution to merging CLI arguments into a common config, that can be applied across all of our binaries. I think that's what figment does and we already use it to handle environment variables, but for now I wanted to push this ASAP so I haven't looked into it yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes this would be nice to have.
#[clap(long, default_value = "te")] | ||
root: String, | ||
#[clap(long)] | ||
mqtt_topic_root: Option<Arc<str>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Renamed flags here to be consistent with tedge-agent
, also because I think --root
or --device
do not give much context to the user of what these options are for, although probably this should be accompanied by help text.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Understood. Consistency is most important!
Codecov Report
Additional details and impacted files
|
Robot Results
|
crates/core/tedge_agent/src/agent.rs
Outdated
let health_actor = HealthMonitorBuilder::new(TEDGE_AGENT, &mut mqtt_actor_builder); | ||
let health_actor = HealthMonitorBuilder::new("health-actor", &mut mqtt_actor_builder); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, the name which is expected here is the name of the service.
This is one of the reasons why the system tests are failing. They expect the "tedge-agent"
to be up, not some unknown "health-actor"
.
However, using "tedge-agent"
here can only be a short term solution. To have the agent running concurrently on several devices, one needs instance specific health status. The better would be to provide here the service topic id. Ignoring the issue with custom device topic id, the service topic id can be forged after the parent topic id. For instance device/child001/service/tedge-agent
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wanted to write a proof of concept for health checks under a new topic scheme and tweaked the converter to convert both ways from old topics to new topics and vice versa, but I didn't know that when subscribing and publishing on the same topic, the client will be sent messages it itself published, resulting in an infinite loop.
This is fixed in MQTT 5, where the subscription option No Local
is used to ask the broker not to echo messages back to the client which published it, but according to @reubenmiller it will be some time before we can use MQTT 5.
To detect whether or not the message is something we published just echoed back to us, we'd have to include some marker data or add other non-trivial logic, so for now I opted to just remain with TEDGE_AGENT
for health checks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good (Apart from the health actor service name)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good in general!
@@ -435,6 +435,14 @@ define_tedge_config! { | |||
}, | |||
|
|||
mqtt: { | |||
/// MQTT topic root |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This comment goes directly to the description showed by tedge config --doc
. So I want to have a bit better description. (Another suggestion is welcomed!)
/// MQTT topic root | |
/// The MQTT root/base topic prefix |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I vote for MQTT root topic prefix
as the word base is used nowhere in the docs.
@@ -38,22 +40,35 @@ pub struct AgentConfig { | |||
pub use_lock: bool, | |||
pub log_dir: Utf8PathBuf, | |||
pub data_dir: Utf8PathBuf, | |||
pub mqtt_device_topic_id: Arc<str>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is really nice! It's a great help to distinguish if a member is immutable or mutable by just looking at the struct data type.
#[clap(long, default_value = "te")] | ||
root: String, | ||
#[clap(long)] | ||
mqtt_topic_root: Option<Arc<str>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Understood. Consistency is most important!
73723ae
to
c8b632e
Compare
Settings `mqtt.topic_root` have been `mqtt.device_topic_id` added to tedge-config and used inside tedge-agent, enabling the agent to be run on a child device and connect to a parent's MQTT broker. Also `--mqtt-topic-root` and `--device-topic-id` flags have been added to `tedge-agent` Signed-off-by: Marcel Guzik <marcel.guzik@inetum.com>
`tedge-log-manager` was updated to use new `mqtt.topic_root` and `mqtt.device_topic_id` config options, still allowing them to be overridden by cli flags. The naming of the flags was made consistent with `tedge-agent` and some code was cleaned up. Signed-off-by: Marcel Guzik <marcel.guzik@inetum.com>
c8b632e
to
bb1ee36
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm okay to approve this PR. I just need a confirmation from @reubenmiller about the names for the two new config settings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved
Align with the change made by thin-edge#2231 * --device => --mqtt-device-topic-id * --root => --mqtt-topic-root Signed-off-by: Rina Fujino <18257209+rina23q@users.noreply.github.com>
Align with the change made by thin-edge#2231 * --device => --mqtt-device-topic-id * --root => --mqtt-topic-root Signed-off-by: Rina Fujino <18257209+rina23q@users.noreply.github.com>
Proposed changes
Settings
mqtt.topic_root
have beenmqtt.device_topic_id
added to tedge-config and used inside tedge-agent, enabling the agent to be run on a child device and connect to a parent's MQTT broker.Also
--mqtt-topic-root
and--device-topic-id
flags have been added totedge-agent
, which can be used to override these values if taken from a configuration file.tedge-log-manager
was updated to use newmqtt.topic_root
andmqtt.device_topic_id
config options, still allowing them to be overridden by cli flags. The naming of the flags was made consistent withtedge-agent
and some code was cleaned up.Types of changes
Paste Link to the issue
#2018
Checklist
cargo fmt
as mentioned in CODING_GUIDELINEScargo clippy
as mentioned in CODING_GUIDELINESFurther comments
This PR completes the Make tedge-agent running on any device section of this TODO list