feat: take tedge.toml backup on tedge config upgrade

[albinsuresh]

Proposed changes

Take tedge.toml backup during tedge config upgrade and notify the user about the existence of any stale backup in tedge config get/set.

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

#4125

Checklist

• I have read the CONTRIBUTING doc
• I have signed the CLA (in all commits with git commit -s. You can activate automatic signing by running just prepare-dev once)
• I ran just format as mentioned in CODING_GUIDELINES
• I used just check 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

❌ Patch coverage is 55.10204% with 22 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...dge_config/src/tedge_toml/tedge_config_location.rs	62.96%	7 Missing and 3 partials ⚠️
crates/core/tedge/src/cli/config/commands/get.rs	0.00%	2 Missing and 2 partials ⚠️
crates/core/tedge/src/cli/config/commands/set.rs	0.00%	2 Missing and 2 partials ⚠️
...ates/core/tedge/src/cli/config/commands/upgrade.rs	0.00%	3 Missing ⚠️
crates/common/tedge_config/src/lib.rs	90.90%	0 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[github-actions]

Robot Results

✅ Passed	❌ Failed	⏭️ Skipped	Total	Pass %	⏱️ Duration
910	1	4	911	99.89	2h40m59.156358999s

Failed Tests

Name	Message	⏱️ Duration	Suite
Set configuration via environment variables for topics	Several failures occurred: 1) 'Warning: Found stale backup file at /etc/tedge/tedge.toml.bak If your current configuration is working, you can safely delete it. ' should be empty. 2) 'Warning: Found stale backup file at /etc/tedge/tedge.toml.bak If your current configuration is working, you can safely delete it. ' should be empty. 3) 'Warning: Found stale backup file at /etc/tedge/tedge.toml.bak If your current configuration is working, you can safely delete it. ' should be empty. [RETRY] FAIL on 3. retry.	0.344 s	Tedge Config Get

[reubenmiller]

I'm wondering how loud we have to be about this backup file.

If we're opening communicating about the file, whilst it is good to make users aware of it, I'm wondering if just will prompt more questions from users. And the downgrade scenario.

For instance, to restore the file, we'd assume just need the tedge.toml from the tedge.toml.bak file, but; what services would need to be restarted, does the new version of the mapper really look at the values within the tedge.toml if there are c8y values present, and the mapper.toml file exists? How does the user know which file is controlling the mapper tedge.toml vs. mapper.toml?

@jarhodes314 any thoughts on this?

[jarhodes314]

It does feel a bit weird to suddenly require a filesystem interaction from the CLI we built largely to prevent the user hand editing files.

I'm also wondering:

1. Do we always create this file, even if there is no change made to tedge.toml (either through a lack of cloud configs or calling it after already upgrading to mapper.toml)?
2. Do we want to enable downgrading? If that's the motivating use case, we probably want to write tedge.toml.bak like we write to tedge.toml, just before we strip it of cloud configs. That way, we don't make this feature essentially pointless is a user runs tedge config upgrade multiple times.

As for what config is read for a cloud, that should be specified in the tedge connect config summary. The logic is that if there are any cloud configs in tedge.toml, then use that (since we only update tedge.toml when the mapper.toml files have been written).

[albinsuresh]

If we're opening communicating about the file, whilst it is good to make users aware of it, I'm wondering if just will prompt more questions from users. And the downgrade scenario.

How about keeping these messages here in the config upgrade but remove the warnings about the backup file from config get/set to reduce the noise?

Do we always create this file, even if there is no change made to tedge.toml (either through a lack of cloud configs or calling it after already upgrading to mapper.toml)?

Currently, yes. That rationale was to enable config upgrade invocations from future tedge versions as well so that we always have the backup of the previous version. But yeah, that introduced the unexpected side effect of the already backed up "original v1 config" getting replaced by an "already migrated v2 config", if config upgrade is invoked multiple times with the same tedge version.

Do we want to enable downgrading? If that's the motivating use case, we probably want to write tedge.toml.bak like we write to tedge.toml, just before we strip it of cloud configs.

The backup_tedge_config logic is called right before migrate_mapper_config. We just need to avoid replacing an existing tedge.toml.bak, if that upgrade invocation did not result in any changes to the tedge.toml.