forked from canonical/checkbox
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Collect system information (New) (canonical#760)
* Init implenation of system info gathering * System information collector init and vendorized inxi * Store actual infos gathered by system_information in the state * Make system_information in state persistent * Include system_information in submission.json * Tests for system_information collectors * Metabox tests to check system_information Minor: also port the fix (no reconnecting message) to inxi job * Updated plainbox tests for new v8 state * Update to overall class style * Test class that resumes the session * Avoid test_assistant's collection of system_information * Test also build_SessionState * Minor: small test for collect * Make system_information executable * Moved responsibility of system_information collection Now the collection is done automatically upon the first get call if no set was done previously. This should be effectively the same as before, the first checkpoint dumps the information, reading it, while a non-fresh session will load a checkpoint setting before reading it Minor: Update tests to mock/check the new path * Refactored Collectors to use metaclasses Minor: moved return_code to output Minor: moved success to property of CollectorOutput Minor: moved str cast to actual cmd Minor: updated tests * Test also CollectorMeta * Change REGISTER_NAME -> COLLECTOR_NAME Minor: Better metaclass docstr * Include inxi in the setup MANIFEST.in Minor: exclude build dir from the installation * Removed success from OutputSuccess and added super * Mock inxi in metabox tests * Removed additional system_information module Minor: updated docstring in init to be up to date to the new content * Documentation about System Information Collection * Fixed paragraphs headers * Address review comments * Rename json_output -> payload * Avoid building json in jinja * Fix typing mistake and update main with the new impl. * Versioned collector outputs Minor: fixed typo * Updated path system_information in vendor * don't jsonify json * Fixed loading mistyping the result of collection
- Loading branch information
Showing
16 changed files
with
37,563 additions
and
36 deletions.
There are no files selected for viewing
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
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
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,79 @@ | ||
# System Information Collection | ||
|
||
Checkbox collects various information about the system using Collectors. | ||
A Collector is a class that wraps a tool that can provide a JSON-serializable | ||
set of information. | ||
When Checkbox starts, it uses these collectors to collect and store | ||
in the session storage all the information it can gather. This is done before | ||
the first session checkpoint is created. From then onward, these information | ||
will remain in memory (and on disk in the checkpoint). When generating a | ||
submission report, Checkbox will include all the information in a top-level | ||
field of the json called "system_information". | ||
|
||
## Format | ||
|
||
A collector can either run succesfully or fail. Regardless of the result, | ||
running a collector will create a new field in the submission file following | ||
this format: | ||
|
||
``` | ||
"system_information" : { | ||
collector_name : { | ||
"version" : collector_version, | ||
"success" : true/false, | ||
"outputs" : { ... } | ||
} | ||
``` | ||
|
||
The outputs field's format depends on the success of the collection. | ||
|
||
If it ran successfully, the output field will have the follwing structure: | ||
|
||
``` | ||
"outputs" : { | ||
"payload" : collector_parsed_json_output, | ||
"stderr" : collector_error_log | ||
} | ||
``` | ||
Where the `collector.payload` is either an array or a dictionary. | ||
|
||
If it failed to run, the output field will have the following structure: | ||
|
||
``` | ||
"outputs" : { | ||
"stdout" : collector_output_log, | ||
"stderr" : collector_error_log | ||
} | ||
``` | ||
Where `collector_error_log` and `collector_output_log` are a string. | ||
|
||
## Creating new collectors | ||
|
||
To create a new collector, one has to create a class that uses the | ||
`CollectorMeta` metaclass. Additionally every collector has to define | ||
a `COLLECTOR_NAME`. Refer to the docstring of `CollectorMeta` for a more | ||
in-dept description. | ||
|
||
> Note: Before creating a new collector, verify if the functionality that | ||
> is needed is already implemented in an existing `collector`. If so, always | ||
> prefer using an already existing collector than creating a new one | ||
|
||
### Using external tools | ||
|
||
If the collector needs a tool, it should be added, when appropriate, to the | ||
vendorized section of Checkbox. Vendorization refers to the inclusion of | ||
external resource to a project's codebase. | ||
|
||
To vendorize a tool, locate the `vendor` module within Checkbox and place | ||
the vendorized version of the tool there, add to `vendor/__init__.py` | ||
the path to the executable that you have added. | ||
|
||
**It is appropriate** to add a vendorized tool when it is an executable script | ||
interpreted by any interpreter pre-installed on **every** version of Ubuntu that | ||
Checkbox supports. The tool must have a compatible license with the Checkbox | ||
license (GPLv3). | ||
|
||
**It is not appropriate** to add a compiled tool of any kind. Since Checkbox | ||
is designed to run on various architectures, compiled tools might not be | ||
universally compatible, leading to operational issues. |
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
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
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
Oops, something went wrong.