feat: enable mosquitto persistence by default

[reubenmiller]

Proposed changes

Open Questions

• Should the logic be moved to the install script so that it can check if the user has configured the persistence true or not and configured the path (with the correct permissions set).

Enable persistence as thin-edge.io heavily relies on retained messages and if mosquitto persistence is not configured, then it can lead to unexpected behavior.

For example (assuming mosquitto persistence is not enabled), if the tedge-agent has already started, and then the user runs tedge connect c8y, then any previously retained message published by tedge-agent will not be republished, and the tedge-mapper-c8y will not know of the previously published retained messages...this leads to supported operations not being sent to the cloud.

Given the impact of not having mosquitto persistence configured, it should not be left up to the user to configure it.

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Improvement (general improvements like code refactoring that doesn't explicitly fix a bug or add any new functionality)
• Documentation Update (if none of the other choices apply)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Paste Link to the issue

• Similar issue: Publish registration and capabilities on te topics when connecting to the MQTT broker #2868

Checklist

• I have read the CONTRIBUTING doc
• I have signed the CLA (in all commits with git commit -s)
• I ran cargo fmt as mentioned in CODING_GUIDELINES
• I used cargo clippy as mentioned in CODING_GUIDELINES
• I have added tests that prove my fix is effective or that my feature works
• I have added necessary documentation (if appropriate)

Further comments

[codecov]

Codecov Report

Attention: Patch coverage is 80.00000% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...s/core/tedge/src/bridge/common_mosquitto_config.rs	80.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

📢 Thoughts on this report? Let us know!

[github-actions]

Robot Results

✅ Passed	❌ Failed	⏭️ Skipped	Total	Pass %	⏱️ Duration
529	0	2	529	100	1h41m1.404084s

[reubenmiller]

Though I'm just reviewing one aspect regarding the persistence_location (https://mosquitto.org/man/mosquitto-conf-5.html).

If non is defined it will choose the current location, but this may be problematic as I don't see the mosquitto service defining the default working directory, which means the current working directory maybe somewhere that the mosquitto user does not have permission to write to.

persistence_location path
The path where the persistence database should be stored. If not given, then the current directory is used.

@albinsuresh @didier-wenzek Any thoughts on this? Should we try to set the default path ourselves? Or even consider creating our own mosquitto configuration package?

[didier-wenzek]

Beware that the file /etc/tedge/mosquitto-conf/tedge-mosquitto.conf is populated only if there is at least one cloud connected.

I would consider to improve the tedge refresh-bridges command to populate this file even if there is no bridge configured. I.e. moving these 2 lines before that one

[albinsuresh]

@albinsuresh @didier-wenzek Any thoughts on this? Should we try to set the default path ourselves? Or even consider creating our own mosquitto configuration package?

Can we not write a new config file with these persistence settings into the /etc/mosquitto/conf.d directory once tedge is installed or as part of tedge init and not wait for tedge connect? Yes, there is the risk of conflicting persistence settings, if the user already has persistence turned on in some other configuration file. But, we can at least check the main /etc/mosquitto/mosquitto.conf file to see if it is already turned ON, before adding ours.

[reubenmiller]

@albinsuresh @didier-wenzek Any thoughts on this? Should we try to set the default path ourselves? Or even consider creating our own mosquitto configuration package?

Can we not write a new config file with these persistence settings into the /etc/mosquitto/conf.d directory once tedge is installed or as part of tedge init and not wait for tedge connect? Yes, there is the risk of conflicting persistence settings, if the user already has persistence turned on in some other configuration file. But, we can at least check the main /etc/mosquitto/mosquitto.conf file to see if it is already turned ON, before adding ours.

Ok, I'm going to move the state of this PR to draft until we work out a way forward.