-
Notifications
You must be signed in to change notification settings - Fork 56
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
Move tedge_to_te_converter to tedge-mapper #2272
Conversation
Having tedge_to_te_converter be a part of tedge-agent introduces 2 problems: 1. If tedge-agent were to be disabled, then MEA topics would no longer be mapped. As tedge-agent is not mandatory for the connection to the cloud to be established, it's reasonable to assume a user who doesn't need the functionality tedge-agent provides to disable it, at which point the converter would not work. 2. tedge-agent is not able to map its own health status messages after it's turned off (which it reasonably could be). Once tedge-agent is updated to work with new health topics while maintaining backward compatibility by converting new health messages back to old topic scheme `tedge/health/...`, one could see an MQTT message log like this: ``` (tedge-agent starts) - PUB te/device/main/service/tedge-agent/status/health "UP" (published by tedge-agent) - PUB tedge/health/tedge-agent "UP" (published by tedge_to_te_converter) (tedge-agent exits) - PUB te/device/main/service/tedge-agent/status/health "DOWN" (published by tedge-agent as last will message) (DOWN message on tedge/health/tedge-agent NOT published by tedge_to_te_converter, because it's exited) ``` leading to an unconsistent state where under a new topic scheme the service is DOWN, but under old topic scheme it's still UP. Having in mind that service status is reported by tedge-mapper to the cloud, and tedge-mapper still uses old health topics, it would be good to have it work while the transistion to new topics is still ongoing. As such, the topic converter was moved into tedge-mapper, because it's the main thin-edge component, responsible for the connection to the cloud and configuration of mosquitto. Moving topic converter solves both above issues because 1. without connecting to the cloud mosquitto is disabled anyway, and 2. after tedge-mapper is disabled, the topic conversion and service status reporting both stop, so there is no opportunity for any inconsistency. Signed-off-by: Marcel Guzik <marcel.guzik@inetum.com>
Robot Results
Failed Tests
|
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.
The code is correct (i.e. moving the topic converter from the agent to the mapper).
So I'm okay to have this PR merged. However, the decision is up to @reubenmiller, as this is impacts the users.
That said, I agree with the first argument for this change (the agent might not be used on all installations) but not with the second one (the issue on tedge/health). I think what is wrong is #2271: the converter should not convert te
topics to tedge
topics, as the plan is to deprecate the latter.
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.
Code changes look good to me. But, I will leave it to @didier-wenzek & @reubenmiller to decide where to put it, either in mapper or agent.
Closing because as @reubenmiller said, it's possible to have multiple mappers running, which make a thin-edge instance connected to multiple clouds simultaneously, in which case moving the converter to the mapper would result in duplicating messages. |
Proposed changes
Having tedge_to_te_converter be a part of tedge-agent introduces 2 problems:
If tedge-agent were to be disabled, then MEA topics would no longer be mapped. As tedge-agent is not mandatory for the connection to the cloud to be established, it's reasonable to assume a user who doesn't need the functionality tedge-agent provides to disable it, at which point the converter would not work.
tedge-agent is not able to map its own health status messages after it's turned off (which it reasonably could be). Once tedge-agent is updated to work with new health topics while maintaining backward compatibility by converting new health messages back to old topic scheme
tedge/health/...
, one could see an MQTT message log like this:leading to an unconsistent state where under a new topic scheme the service is DOWN, but under old topic scheme it's still UP.
Having in mind that service status is reported by tedge-mapper to the cloud, and tedge-mapper still uses old health topics, it would be good to have it work while the transistion to new topics is still ongoing.
As such, the topic converter was moved into tedge-mapper, because it's the main thin-edge component, responsible for the connection to the cloud and configuration of mosquitto. Moving topic converter solves both above issues because 1. without connecting to the cloud mosquitto is disabled anyway, and 2. after tedge-mapper is disabled, the topic conversion and service status reporting both stop, so there is no opportunity for any inconsistency.
Types of changes
Paste Link to the issue
Checklist
cargo fmt
as mentioned in CODING_GUIDELINEScargo clippy
as mentioned in CODING_GUIDELINESFurther comments