Support running tedge-agent on a child device

[reubenmiller]

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

The tedge-agent provides a nice software management plugin interface. It would be useful if the tedge-agent could be modified to allow it to run both on the main device and on/as a child device. This would enable users to get out-of-the-box functionality for child devices with zero coding! In the future it could also be extended to the other plugins to support reusing all of the existing components as either a main device or a child device.

Describe the solution you'd like

There are two areas that will need addressing to enable this feature.

Area 1: Changes to the tedge-agent to support different runtime roles

• Not all features of the tedge-agent make sense running when running as a child device, for example the http server should not be started when running as a child device.
  • Expected functionality when running as a child
    • Software management
    • Restart operation
  • Disable functionality when running as a child
    • http service
• The MQTT client id should be configurable so that the client id does not conflict with the tedge-agent running on the main device
• The MQTT topics used by the tedge-agent should be configurable to use the appropriate topics depending on its current role (e.g. running as a main device or as a child device)

Area 2: Changes to the tedge-mapper to support sending commands to child devices

• Change the tedge-mapper to support routing the operations for child devices to tedge/ topics. For example tedge/child/{childid}/commands/.... The specifics of the topic naming is dependent on Optimize MQTT topic structure for main and child devices #2005

Notes

• The tedge-mapper-template PoC could be used to try out possible new MQTT topic structures before the changes are done to the tedge-mapper

Describe alternatives you've considered

Additional context

An PoC has already been created to show how the MQTT client id and the topics could be made configurable. A configurable topic prefix is used to control whether the tedge-agent should behave as a main device or a child device.

[didier-wenzek]

Required changes

Make tedge-agent running on any device

• Add to tedge-agent, the cli argument --device <DEVICE> (default: device/main//)
• Add to tedge-agent, the cli argument --root <ROOT> (default: te/)
• Consider to add root.topic and device.topic to tedge config (if so do the same for tedge-log-plugin)
• Change the MQTT session name of tedge-agent (along the same line as for tedge-log-plugin)
• Added in Add mqtt.topic_root and mqtt.device_topic_id options #2231

Capabilities:

• Disable file-transfer, if not running on the main device
• Disable tedge to te message translation, if not running on the main device

Health checks:

• Expect health checks on <root>/<device-topic-id>/cmd/health/check
• Publish health check on <root>/<device-topic-id>/status/health
• Stop subscribing to tedge/health-check/tedge-agent (when the mapper has been updated accordingly).

Software list:

• Write the documentation (using the former specs)
• Publish the list of software types on <root>/<device-topic-id>/cmd/software-list
• Update the agent, to subscribe to <root>/<device-topic-id>/cmd/software-list/<cmd-id> and publish responses on the same topic.
• Update the mapper to publish software requests on <root>/<device-topic-id>/cmd/software-list/<cmd-id> and to expect responses on the same topic.
• Stop subscribing to tedge/commands/req/software/list.

Software update:

• Write the documentation (using the former specs)
• Expect the list of software types on <root>/<device-topic-id>/cmd/software-update
• Update the agent, to subscribe to <root>/<device-topic-id>/cmd/software-update/<cmd-id> and publish responses on the same topic.
• Update the mapper to publish software requests on <root>/<device-topic-id>/cmd/software-update/<cmd-id> and to expect responses on the same topic.
• Stop subscribing to tedge/commands/req/software/update.

Restart operation

• Write the documentation (I failed to find former specs)
• Publish restart capability on <root>/<device-topic-id>/cmd/restart
• Update the agent, to subscribe to <root>/<device-topic-id>/cmd/restart/<cmd-id> and publish responses on the same topic.
• Update the mapper to publish restart requests on <root>/<device-topic-id>/cmd/restart/<cmd-id> and to expect responses on the same topic.
• Stop subscribing to tedge/commands/req/control/restart.

[reubenmiller]

@didier-wenzek Can you please update the status of this ticket?

[didier-wenzek]

Child-support has been implemented by #2307.
The agent documentation has been updated: #2235:

• How to launch tedge-agent on the main device as well as on a child device
• Tedge MQTT v1 protocol used by the agent for restart of device (main or child)
• Tedge MQTT v1 protocol used by the agent for software_list of device (main or child)
• Tedge MQTT v1 protocol used by the agent for software_update of device (main or child)

Topic used for health checks have been updated by #2274.
Documentation is addressed by #2375

• Publish health status on te/$(agent-service-id)/status/health for agent running on main or child device.
• Respond to health check on te/$(agent-service-id)/cmd/health/check for agent running on main or child device.
• Respond to health check on te/$(device-id)/cmd/health/check for agent running on main or child device.

[gligorisaev]

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

• Test for ticket exists in the test suite.
• tests/RobotFramework/tests/tedge_agent/tedge_agent.robot
• tests/RobotFramework/tests/cumulocity/restart/restart_device.robot
• tests/RobotFramework/tests/cumulocity/restart/restart_device_child.robot
• tests/RobotFramework/tests/cumulocity/service_monitoring/service_monitoring.robot
• QA has tested the bug and could not reproduce it anymore.

This ticket covers the #1470 as well