Integrate the command handler with the module manager #190
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jr0me
requested review from
aritosteles,
TomasTurina,
sdvendramini and
Nicogp
jr0me
force-pushed
the
enhancement/146-integrate-the-command-handler-with-the-module-manager
branch
from
5bc8d09 to
c5bdc88
Compare
aritosteles
reviewed
Sep 30, 2024
jr0me
changed the title
nbertoldo
force-pushed
the
enhancement/17-migrate-syscollector-to-inventory-at-new-agent
branch
from
4eaafd1 to
ac5c5e9
Compare
Base automatically changed from
enhancement/17-migrate-syscollector-to-inventory-at-new-agent
to
master
October 1, 2024 23:08
The class previously named `Command` had a public data member `m_command`, which used a naming convention intended for private members. Since all public members should follow PascalCase, according to the current clang tidy rules, `m_command` was renamed to `Command`, causing a name collision with the class itself. To resolve this and better reflect the class’s role, which encompasses more than just the command (including data related to the storage and processing of commands), the class has been renamed to `CommandEntry`.
Since they are public they should not use the "m_" prefix.
Public members shouldn't use the "m_" prefix.
There will be some common usage of the classes defined in this header: Status, CommandEntry. So we begin here the separation from the commond store specific component. The idea is that Modules will require to also return a Status code from the result of a command execution.
… message This will be used by the CommandEntry and by the modules as the execution result returned type.
Currently only Inventory is enabled.
The reason behind this is that it is recommended to avoid using references on coroutines, hence the pass by value is intentional. There's a "conflict of interests" between two clang tidy checks here, the one being ignored here and another that warns about using references on coroutines, fixing the former triggers the latter. But as explained above the copy is preferred here.
jr0me
force-pushed
the
enhancement/146-integrate-the-command-handler-with-the-module-manager
branch
from
70595a8 to
11f3c67
Compare
TomasTurina
approved these changes
Oct 2, 2024
TomasTurina
deleted the
enhancement/146-integrate-the-command-handler-with-the-module-manager
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This pull request integrates the command handler with the module manager, allowing to send commands to the corresponding modules, and introduces updates and refactoring to the command handling and storage mechanisms within the Wazuh agent. The functions executing commands have been modified to use awaitables (so they are effectively coroutines). Some other small refactorings are made.
Tests