Handle unknown configuration gracefully

[reubenmiller]

Is your feature improvement request related to a problem? Please describe.

Soften strict parsing of tedge.toml and system.toml to handle unknown section or properties so that they do not prevent the service from starting. The unknown sections/properties could be printed out in warning log messages instead.

Since multiple services read the tedge.toml file; tedge-mapper, c8y-log-plugin and c8y-configuration-plugin. When a component is updated (and the configuration is automatically updated via tedge --init, then the other non-updated components will not start up as they will throw an exception (and not start) due to detecting an unknown configuration section.

Motivation

• More robust: tedge should not explode if some users accidentally adds invalid configuration
• It allows future configuration to be rolled out and is not destructive
• Decouple components and the reliance that they are updated at the exact same time

Scenario

The following scenario would leave to 2 services not starting.

1. A new version of tedge and its components
2. The user updates tedge via Cumulocity and forgets to update the other components like tedge_mapper, c8y_log_plugin and c8y_configuration_plugin)
3. The user adds the new configuration option (introduced in the new tedge version)
4. The user reboots the device (due to other activities)
5. Now c8y-mapper-*, c8y-log-plugin and c8y-configuration-plugin services do not start because they complain about an unknown section in tedge.toml

Example error (from the tedge-mapper-c8y service

tedge-mapper-c8y.log
Error: TOML parse error
Caused by:
    unknown field `http`, expected one of `device`, `c8y`, `az`, `mqtt`, `software`, `tmp`, `logs`, `run` at line 21 column 1

Describe the solution you'd like

• When parsing tedge.toml unknown sections or properties should not prevent any service from starting
• Unknown sections or properties should be printed out as warning log messages (so the user is aware that there are some invalid configuration)

Describe alternatives you've considered

The dependency to the configuration file schema could be managed via the debian package dependency mechanisms. However this complicates the installation of different packages and would only be possible when using apt-get install rather than using dpkg -i.

And the dependency management system does not solve the robustness issue where users can break tedge by an accidental typo.

[didier-wenzek]

Another motivation is to let an external plugin use the same configuration file instead of coming with yet another configuration file.

[6367f766]

Does this ticket require a system test? @didier-wenzek, @reubenmiller

[reubenmiller]

Does this ticket require a system test? @didier-wenzek, @reubenmiller

Yes please.

[6367f766]

How to test:

Having an unknown key in the tedge.toml file should not prevent the startup of the services.

• add a new and unknown key in /etc/tedge/tedge.toml for example:

[another]
key = "value"

• check that tedge connect works.

[gligorisaev]

Tested