Tedge config settings to selectively enable/disable supported operations of tedge-agent

[albinsuresh]

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

Since the tedge-configuration-plugin and the tedge-log-plugin have been merged into the tedge-agent, there should be a mechanism to disable their corresponding operations (config_snapshot, config_update, log_upload) should the user want to opt-out of their usage. Previously the user could have just disabled the tedge-log-plugin or tedge-configuration-plugin service, but since it is now one single service (tedge-agent), another mechanism is required to disable the functionality.

Describe the solution you'd like

Provide a tedge config setting: agent.enable.<op_name> to enable/disable each supported operation individually as follows:

The scope is explicitly limited to the functionality previously delivered by the tedge-log-plugin and tedge-configuration-plugin (e.g. log_upload, config_update and config_snapshot).

[agent]
enable.log_upload = true
enable.config_update = true
enable.config_snapshot = true

Describe alternatives you've considered

The enable settings could also be placed under those operation specific config roots as follows:

[configuration]
enable = true

[log_upload]
enable = true

# ...other op sections

The only downside with this approach is that the agent is not mentioned anywhere in the key and a user may misinterpret it as the whole feature is disabled, whereas we're only disabling the inbuilt ops handling by the agent.

But the proposed solution also comes with the downside that the enable/disable settings are isolated from the rest of the feature specific config settings mentioned above. Ideally, those feature specific settings should also be moved under the agent root setting, alongside their enable keys, without breaking backward compatibility as follows:

[agent.software_management]
enable = true

[agent.software_management.plugin]
default = "apt"
max_packages = 1000

[agent.firmware_management]
enable = true

[agent.firmwaremanagement.child.update]
timeout = 30

[agent.config_management]
enable = true

[agent.log_management]
enable = true

Additional context

[reubenmiller]

@albinsuresh I would agree with your proposed solution in having a single section which controls whether the agent is responsible for the given commands or not (as this is more agent functionality rather than the underlying actor for each command handling).

Though maybe a slight edit with of change the name of the section to agent.command so it matches up with the /cmd/ that we use in the MQTT topic to trigger the commands:

[agent]
enable.config_update = true
enable.config_snapshot = true
enable.log_upload = true

Update 2023-12-15: The ticket description has been updated with the revised implementation.

[reubenmiller]

The implementation can now be tested used the following procedure:

1. Enable/Disable a feature via tedge config, e.g. tedge config set enable.log_upload
2. Restart the tedge-agent service
3. Check if the device reacts to operations or not depending on if the feature is enabled or disabled

[gligorisaev]

QA has thoroughly checked the feature and here are the results:

• [x] Test for ticket exists in the test suite.
• tests/RobotFramework/tests/cumulocity/configuration/configuration_operation.robot
• tests/RobotFramework/tests/cumulocity/log/log_operation.robot
• [x] QA has tested the function and it's functioning according description.