Describe the bug

The tedge post installation script can fail at the tedge refresh-bridges step if the following is true:

• A bridge is connected and configured
• The c8y.url config is removed the user forgets to run tedge disconnect c8y

The output of tedge refresh-bridges shows that the c8y.url is expected to recreate the bridge (as it assumes that if the bridge already exists then it should be recreated regardless if the c8y.url has been removed or not...see the "expected behaviour" for possible actions)

$ tedge refresh-bridges

Refreshing bridge Cumulocity
Error: failed to Refresh all currently active mosquitto bridges (restarts mosquitto)

Caused by:
    A value for 'c8y.url' is missing.
        A value can be set with `tedge config set c8y.url <value>`

Whilst this situation is unlikely it does cause an issue as it results in the Debian APT "broken packages" which results in other calls to apt to fail.

However, the following commands can be used to resolve the APT "broken packages" state (where "-f" means "fix" and not "force"):

tedge disconnect c8y
apt-get install -f

To Reproduce

The same package installation setup can be reproduced without having to actually upgrade the Debian package, but instead just replicating the important steps which lead to this situation:

1. Install thin-edge.io

2. Connect thin-edge.io to Cumulocity

   tedge config set c8y.url example.c8y.io
   tedge connect c8y

   Note: Creating and uploading the certificate is not shown here

3. Unset the c8y.url value (and forget to run tedge disconnect c8y)

4. Refresh the bridges

   tedge refresh-bridges

Expected behavior

The following are the proposed options, though some consensus might be needed before doing the implementation.

Option 1: Don't fail the installation if refreshing the bridge fails, only print a warning

In the tedge post installation script, only print out a warning if the tedge refresh-bridges exits with a non-zero exit code so that the packages is not marked as "failed".

This would allow accidental corruption of the tedge.toml file (or c8y.url setting) to not lead to the bridge connection (and possible the only cloud connection) from being removed as this would result in the device being unreachable. This would potentially give a device operator a chance to fix the situation remotely.

The configuration/package_scripts/tedge/postinst file could be changed as follows:

Before

tedge refresh-bridges

After

tedge refresh-bridges || echo "Warning: Failed to refresh bridges. Continuing anyway"

Option 2: Remove the bridge if the corresponding c8y.url no longer exists

If a bridge's associated url has been removed from the settings, then the bridge connection should be removed.

Whilst this option would be "more correct" (e.g. someone probably just forgot to run tedge disconnect c8y), it could lead to a loss of connectivity if the unsetting of the c8y.url was accidental, or due to a corrupt configuration (maybe someone accidentally applied a tedge.toml via the configuration management feature and forgot to add the c8y.url value).

Screenshots

Environment (please complete the following information):