tedge refresh-bridges causes package installation to be marked as failed when c8y.url has been unset

[reubenmiller]

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):

Property	Value
OS [incl. version]	Poky (Yocto Project Reference Distro) 5.0.6 (scarthgap)
Hardware [incl. revision]	Raspberry Pi 4 Model B Rev 1.1
System-Architecture	Linux rpi4-dca632486720 6.6.22-v8 #1 SMP PREEMPT Tue Mar 19 17:41:59 UTC 2024 aarch64 GNU/Linux
thin-edge.io version	tedge 1.4.3~148+g75d0797
Additional context

[albinsuresh]

Option 2 sounds far more disruptive compared to Option 1 as it can disrupt even a perfectly working setup just because someone made a mistake. Option 1 is far more safer in the sense that it can only disrupt an extreme corner case as described in the ticket.

How about a third option that makes tedge connect keep a read-only copy of the settings it used to establish the connection so that we can fall back to those settings when tedge refresh-bridges fails with the latest settings?

[reubenmiller]

How about a third option that makes tedge connect keep a read-only copy of the settings it used to establish the connection so that we can fall back to those settings when tedge refresh-bridges fails with the latest settings?

Yeah that would be interesting. Though I guess this would be part of a bigger robustness improvement to avoid unexpected changes:

• Prevent against accidental changes
• Support robust tenant migration action (e.g. move device from tenant 1 to tenant 2)
• Support more robust rollback strategies whilst upgrading thin-edge.io (e.g. as tedge config list|get can edit the tedge.toml file)

So for now, I'll implement Option 1 (to prevent immediate problems), and keep this ticket open until we define what we want to achieve.