feat: Support multiple cloud profiles

[jarhodes314]

Proposed changes

Following the merging of #3262 early to limit conflicts, there are some outstanding tasks:

Current status:

• Allow profiled configurations to be overridden with environment variables
• Change the bridge local client ID to be backwards compatible, to avoid lost messages
• Test the conflicting configuration validations for tedge connect (unit tests now added, will add a system test too)
• Clean up the system test that was largely copied from the existing configuration operation test file
• Support a --profile argument as an alternative to cloud@profile syntax to make scripting simpler

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

• Allow easy configuration of cloud-profiles #3206

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

[jarhodes314]

@albinsuresh pointed out doing this will bypass the automatic cleanup we get for the devices we create. I'm not sure exactly how best to perform this clean-up. @reubenmiller are you able to help with this?

[reubenmiller]

We can ignore the cleanup for now (for this PR). We can easily add a new keyword to register a device for cleanup once the suite has finished.

[codecov]

Codecov Report

Attention: Patch coverage is 85.04673% with 112 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
crates/core/tedge/src/cli/common.rs	41.46%	23 Missing and 1 partial ⚠️
crates/core/tedge_mapper/src/lib.rs	0.00%	20 Missing ⚠️
crates/core/tedge/src/cli/certificate/cli.rs	5.26%	15 Missing and 3 partials ⚠️
crates/core/tedge/src/cli/connect/command.rs	95.87%	11 Missing and 4 partials ⚠️
crates/core/tedge/src/cli/config/cli.rs	50.00%	8 Missing ⚠️
...ommon/tedge_config/src/tedge_config_cli/figment.rs	91.78%	0 Missing and 6 partials ⚠️
...s/extensions/c8y_mapper_ext/src/service_monitor.rs	33.33%	4 Missing and 2 partials ⚠️
crates/common/tedge_config_macros/src/multi.rs	44.44%	4 Missing and 1 partial ⚠️
crates/core/tedge/src/cli/log.rs	0.00%	5 Missing ⚠️
...rates/common/tedge_config_macros/impl/src/query.rs	98.43%	2 Missing ⚠️
... and 3 more

Additional details and impacted files

📢 Thoughts on this report? Let us know!

[github-actions]

Robot Results

✅ Passed	❌ Failed	⏭️ Skipped	Total	Pass %	⏱️ Duration
545	0	2	545	100	1h37m27.122302s

[didier-wenzek]

$ invoke flake-finder --test-name "Test non-mosquitto-bridge service status mapping" --iterations 10 --outputdir output_ff --clean
------------------------------
Overall: PASSED
Results: 10 iterations, 10 passed, 0 failed

[didier-wenzek]

Approved.

[didier-wenzek]

A comment would help to understand when to use CloudArgs vs OptionalCloudArgs vs Option<ProfileName> as a clap argument.

• tedge cert create uses OptionalCloudArgs letting the user creates a certificate for a specific cloud profile as well as a generic one not specifically attached to some cloud profile.
• tedge connect uses CloudArgs because a cloud is required, possibly with a specific profile.
• tedge cert upload c8y uses Option<ProfileName> because this feature is only available for Cumulocity.

[jarhodes314]

I've now fixed this by changing this to be a subcommand, so we can wrap the result is in Option. I guess the point around cert upload is still relevant, but I think it's fairly obvious why that is a special case.

[reubenmiller]

Really nice feature. Just a few open todos:

Summary

• Item 1: Help for tedge cert create help text has duplicate --device-id entries
• Item 4: Add TEDGE_CLOUD_PROFILE variable to the command's help text
• Item 6: Remove references to @ syntax in error message and config list

In Follow-up PR

• Item 2: include mapper config when testing the cloud connection (same as tedge connect c8y)
• Item 3: add cloud profile information into the tedge connect output
• Item 5: Add maintainer script snippets to handle systemd template certificates - @reubenmiller

See the following sections for the addition details.

Action item details

Item 1: Help for tedge cert create help text has duplicate --device-id entries

tedge cert create c8y --help

Usage: tedge cert create --device-id <ID> c8y [OPTIONS] --device-id <ID>

Ideally the following should be supported:

tedge cert create c8y [OPTIONS] --device-id <ID>

tedge cert create c8y --device-id bar0001 --profile staging-latest

Item 2: include mapper config when testing the cloud connection (same as tedge connect c8y)

The test command would be more useful if it showed the configuration details as well during the test.

The following only shows that the connect to the "cloud" is ok, but not the url of the cloud (and not the tenant).

$ tedge connect c8y --profile staging-latest --test

Verifying device is connected to cloud... ✓
Checking Cumulocity is connected to intended tenant... ✓
Connection check to c8y cloud is successful.

Item 3: add cloud profile information into the tedge connect output

tedge reconnect c8y --profile staging-latest
Disconnecting from Cumulocity
Removing bridge config file... ✓
Restarting mosquitto to apply configuration... ✓
Disabling tedge-mapper-c8y@staging-latest... ✓
Reconnecting with config:
        device id: TST_develop_refined_assurance
        cloud host: iot.latest.stage.c8y.io:8883
        certificate file: /etc/tedge/device-certs/tedge-certificate.pem
        bridge: mosquitto
        service manager: systemd
        mosquitto version: 2.0.11

For example:

Reconnecting with config:
        device id: TST_develop_refined_assurance
        cloud host: iot.latest.stage.c8y.io:8883
        cloud profile: staging-latest
        cloud type: c8y
        certificate file: /etc/tedge/device-certs/tedge-certificate.pem
        bridge: mosquitto
        service manager: systemd
        mosquitto version: 2.0.11

Item 4: Add TEDGE_CLOUD_PROFILE variable to the command's help text

For example, add the env: section to the flag's help text (you may have to do this manually).

$ tedge connect c8y --help
Usage: tedge connect c8y [OPTIONS]

Options:
      --profile <PROFILE>
          The cloud profile you wish to use
          [env: TEDGE_CLOUD_PROFILE]

If it is too much effort, then we can add this in the next release (as we're having a bit of feature creep)

Item 5: Add maintainer script snippets to handle systemd template services

The systemd template services (e.g. [email protected]) are not correctly stopped/started/enabled in deb and rpm maintainer scripts (e.g. preinst, prerm, postinst).

Example snippet:

systemctl show "tedge-mapper-c8y@*" --state=loaded --property=Id --value --no-pager | while read -r UNIT; do
        echo "Restart service: $UNIT" >&2
        systemctl restart "$UNIT"
done

Item 6: Remove references to @ syntax in error message and config list

Remove guidance using the @ suffix syntax from error messages.

$ tedge connect c8y --profile staging-latest
error: The configurations: c8y.bridge.topic_prefix, [email protected]_prefix should be set to different values before connecting, but are currently set to the same value

Why is the @ syntax shown in the config list

$ tedge config list 'c8y@'

Why can't it following the tedge.toml data format?

For example, given:

[c8y.profiles.staging-latest]
url = "iot.latest.stage.c8y.io"

Then just support the syntax as follows:

c8y.profiles.staging-latest.url

[didier-wenzek]

Approved.

Thank you for your sustained effort on improving the UX experience of users and devs using tedge config.

[reubenmiller]

Retested the changes and everything looks great. I'll create a follow up PR to address the packaging changes (e.g. maintainer script changes regarding the service management).

[albinsuresh]

LGTM.

[albinsuresh]

Ideally, it would have been better if this was not done from this simple "conversion" function, but done from the calling process_health_status_message function. But I understand that doing this from here, when you have access to display_name simplifies the code.

[albinsuresh]

Suggested change

	*** Test Cases ***
	*** Test Cases ***
	# Since the test framework does not have access to multiple cloud tenants,
	# multi cloud profile support is tested by connecting the same device to the same cloud
	# using different external identities configured using different profiles.
	# This setup results in a single "device" having two device twin identities in the cloud.
	# That same "device" can be controlled via either twins.

Adding some commentary would be nice to help others looking at this test and going: "where are those multiple cloud connections?"