Empty workflow log files generated for config and log management operations

[albinsuresh]

Describe the bug

The workflow log files created on execution of configuration and log management operations are empty as seen here:

$ ls -l /var/log/tedge/agent/
total 24
-rw-r--r-- 1 tedge tedge    0 Apr 23 13:44 workflow-config_snapshot-c8y-mapper-35841214.log
-rw-r--r-- 1 tedge tedge    0 Apr 23 13:32 workflow-log_upload-c8y-mapper-35588951.log

To Reproduce

Execute any config management or log management operation and check the corresponding workflow log files at /var/log/tedge/agent/

Expected behavior

The workflow log files should properly capture the state transitions of these operations, just like it does for software management or device restart operations

Additional context

This is a side effect of the config management and log management actors being integrated with tedge-agent as independent actors and not via the tedge_operation_converter as it is done for software manager and restart manager actors.

[didier-wenzek]

Indeed, something to do. However, this is unfortunately far beyond just "fix logging".

• The config and log management operations are currently not managed by the workflow sub-system.
• Till this is fixed:
  • Users cannot provide enhanced version of the log and config operations
  • A workflow cannot trigger a log or config update as a sub operation
  • The latter point makes this issue high priority to support device profile.
• The fact the logs are empty is actually a bug:
  • the log file is created on reception of an MQTT message for a command,
  • but never populated as the workflow sub-system is not even aware of those operations.

[didier-wenzek]

Thanks to https://github.com/thin-edge/thin-edge.io/pull/2844, the log and config operations are now plainly supported by the workflow feature:

• Users can provide enhanced version of the log and config operations
• A user-defined workflow can trigger a log or config update as a sub operation
• Workflow log files are generated for log and config commands as for the other commands.

[gligorisaev]

This bug was reproducable before the PR's that are fixing it were merged. I confirm that this bug is NOT reproducable anymore.

Review done for following tests: tests/RobotFramework/tests/cumulocity/software_management/software.robot tests/RobotFramework/tests/cumulocity/configuration/configuration_operation.robot tests/RobotFramework/tests/cumulocity/log/log_operation.robot

software.robot

In this Test Suite following Test Steps are added:

Operation log uploaded automatically with default auto_log_upload setting as onFailure Operation log uploaded automatically with default auto_log_upload setting as always Operation log uploaded automatically with default auto_log_upload setting as never

In this Test Suite following new Keywords are added:

Validate operation log uploaded Validate operation log not uploaded

Overall, the new test cases and keywords are well-designed with clear documentation and robust validation steps. Well-documented steps and expected outcomes.

configuration_operation.robot

In this Test Suite following Test Steps are added:

Trigger config_snapshot operation from another operation Trigger custom config_snapshot operation Trigger config_update operation from another workflow Trigger custom config_update operation

and following keywords:

Customize config operations Restore config operations Customize Operation Workflows

• The code is consistent with the use of indentation, naming conventions, and comments for clarity.
• Each keyword and test case is documented with arguments and steps, making it easier to understand the purpose and functionality.
• Keywords are defined to encapsulate reusable actions, promoting reusability and reducing duplication.

log_operation.robot

In this Test Suite following Test Steps are added:

Trigger log_upload operation from another operation Trigger custom log_upload operation

and following keywords:

Customize Operation Workflows Customize log_upload operation Restore log_upload operation

• The formatting of the new test cases and keywords is consistent with the existing ones, which aids readability and maintainability.
• The names of the test cases and keywords are descriptive, clearly indicating their purpose.
• The sequence of operations and checks within each test case and keyword appears logical and appropriate for the intended test scenarios.
• These steps ensure that the tests cover the intended functionality thoroughly and provide clear feedback on the system's behavior under different conditions