aboutsummaryrefslogtreecommitdiffstats
path: root/tests/report_tests/plugin_tests
Commit message (Collapse)AuthorAgeFilesLines
* [krb5] Enable on Ubuntu/Debian, expand package tupleJake Hunsaker2022-10-101-0/+39
| | | | | | | | | | | | | | It was found that the `krb5` plugin was not executing on Ubuntu/Debian systems due to a legacy change that inadvertently removed support for those distributions. Re-enable support by defining a new plugin class for those distros, setting the kdc directory appropriately. Additionally, expand the package tuple to include newer package names. Closes: #3041 Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
* [process,PackageManager] Create a mapping of processes to packagesJake Hunsaker2022-09-281-1/+1
| | | | | | | | | | | Adds a new manual collection to the `process` plugin, that tries to compile a mapping of running processes' binaries to an owning package via the package manager. As such, package managers now have a new `pkg_by_path()` method that serves this purpose. Closes: #1350 Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
* [Plugin] Allow for manual collections during collect phaseJake Hunsaker2022-09-281-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | Historically, sos has limited collections to existing files and command output. While there have been many reasons for this, there have also been several exceptions made to current plugins as well as ongoing requests for data that is not currently provided via existing commands. As sos evolves, it should in turn be more capable to provide diagnostic data beyond what is strictly available via command outputs. As such, add a new step to the collection phase that allows plugins to perform these manual data collections. Plugins may now define their own `collect()` method to do so, thus moving the existing exceptions out of `setup()` phase execution. To aide in writing these collections to the plugin directory, a new `collection_file()` generator has been added which will handle creating, managing, and closing the new file so that plugins only need to be concerned with the content being written to such files. Plugin contributors should note that these manual collections are executed at the end of the collection phase - meaning they are more likely to be skipped or interrupted due to plugin timeouts. Closes: #2992 Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
* [teamd,tests] Add a test for teamd plugin and device enumerationJake Hunsaker2022-08-101-0/+46
| | | | | | | | | | | | | Adds a new test case for the `teamd` plugin that also inherently acts to test team device enumeration. Included with this test case is an addition to the base test classes that allows for tests to define a `post_test_tear_down()` method that will be run at the end of each test execution to allow for manual cleanup - in this case deleting a 'fake' team device created for the test. Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
* [tests] Update networking test in suiteJake Hunsaker2022-07-251-0/+7
| | | | | Adds a new test to the networking plugin test to ensure we iterate correctly over network devices.
* [logs] Drop catalog from `this` and `last` bootJake Hunsaker2022-07-061-1/+1
| | | | | | | | | Removes catalog entries from the journal collection for `this` and `last` boot collections. Closes: #2132 Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
* [Plugin] Allow plugins to define default command environment varsJake Hunsaker2022-03-251-0/+44
| | | | | | | | | | | Adds the ability for plugins to define a default set of environment vars to pass to all commands executed by the plugin. This may be done either via the new `set_default_cmd_environment()` or `add_default_cmd_environment()` methods. The former will override any previously set values, whereas the latter will add/update/modify any existing values. Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
* [tests] Increase stagetwo log test timeoutJake Hunsaker2021-10-181-0/+1
| | | | | | | | | | | As an interim stopgap measure, increase the timeout for the stagetwo `logs` test to allow for more time for handling random data generation and logging, until we're able to define a better/more efficient way to generate this data within the test suite. Related: #2700 Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
* [tests] Enable verbosity by default for all testsJake Hunsaker2021-10-181-1/+1
| | | | | | | | | | The debug level messages gated by `-v` are very helpful for diagnosing test failures, but currently not all tests specify the use of verbosity. Make use of verobsity a default parameter for all test runs to address this. Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
* [Plugin] Improve add_string_as_file collection and manifest recordingJake Hunsaker2021-09-172-0/+43
| | | | | | | | | | | | | | | | | | | This commit allows plugins that call `add_string_as_file` to specify if the string should be written to `sos_strings/$name/` (current behavior) or if it should be written to `sos_commands/$name/` which may be desireable for organizational purposes for plugin collections. `add_string_as_file()` has also been updated to write to a plugin's manifest section for any files written this way. Accordingly, the method will now accept a `tags` parameter to add specified tags to the manifest entry. Certain plugins directly calling this method have been updated, but the existing logic to write truncated data to `sos_strings/` remains untouched, and will not generate manifest entries (as those should already be handled by the method that trigged the truncated collection). Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
* [Plugin] Add default journal collection for Plugin servicesJake Hunsaker2021-06-141-0/+42
| | | | | | | | | | | | | | | | | Adds automatic collection of journals for any service defined in a plugin's `services` tuple, if that service exists on the system. Updates several plugins to define a `services` tuple in place of manually calling `add_journal()` (and as a bonus, removing redundant `add_service_status()` calls that are already performed based on the tuple). Additionally, add an appropriate tag to each `add_journal` call for easier collection lookup in the manifest. Resolves: #2579 Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
* [tests|logs] Stream test data to journal, change inspected journalJake Hunsaker2021-05-051-9/+13
| | | | | | | | | | | | Changes the logs pre_sos_setup() to write to the journal using a stream rather than writing several MB directly all at once. This fixes an issue where using the `journal.send()` method from the systemd module would result in no data being written to the journal during the test setup. Second, switch over to inspecting the full journal rather than the most recent boot journal. Related: #2499
* [tests] Correct test package installationJake Hunsaker2021-05-051-7/+6
| | | | | | | | | | | | | | | | First, correct the logs plugin stagetwo test to specify the needed package in a list, and second move the import to within the test class that needs it so that we don't fail on the stageone tests if the package is not present. Second, correct the journal injections that this plugin test does to use `pre_sos_setup()` instead of overriding `setup_mocking()`, and call the former after the mocking has been setup. Finally, add the resulting size of the collected journal if we fail the size requirements of the test. Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
* [Plugin] Make command output size limiting obviousJake Hunsaker2021-04-301-0/+4
| | | | | | | | | | | | | | | | | | | | | When command output is size limited it should be made obvious that it is not the whole output of the command, beyond the collected output (most likely) starting in the middle of a string. To do this, we add a 'truncated' key to the results dict returned by `sos_get_command_output()`, which is set based on if the `AsyncReader` was filled during command execution. From that, first log if a command was truncated. Second, instead of dropping the collected output in the normal plugin directory, instead drop it into `sos_strings` with a `.tailed` extention to mimic how we handled tailed file collections. Finally, add a symlink from the plugin dir with the original filename that points to the `sos_strings` path. Closes: #1332 Resolves: #2506 Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
* [process] Collect per-process files from /procJake Hunsaker2021-04-161-0/+29
| | | | | | | | | | | | | | | | | | | | Adds collection of per-process files from /proc/$pid, limited to a number of pids controlled by the new `process.numprocs` option. This option will default to the first 2048 processes. Using a value of `0` for this option will result in all pids being collected. In testing, the initial limit of 2048 process did not significantly raise collection time or archive size. Note however, that collection of 20k or more processes does show a significant increase in plugin execution time and archive size. This is however tempered, by the whole-plugin timeout that sos imposes. Related: #436 Closes: #542 Resolves: #1783 Resolves: #2498 Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
* [tests] Add plugin tests for basic functionalityJake Hunsaker2021-04-153-0/+137
| | | | | | | | | | | | Adds several plugin tests for plugins that can be expected to run on all distributions, in particular these tests are including mostly Stage Two tests. As such, these tests are only recommended to be run on test machines. Related: #2431 Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
* [tests] Start using avocado for test suiteJake Hunsaker2021-04-152-0/+31
This commit represents the start of an overhaul of the test suite used by sos. Note that several more commits to follow will be required in order for the test suite to be considered stable. The new test suite will use the avocado-framework to build out new tests. This first part adopts a new 'stageX' naming scheme for our tests as follows: stage0 -> Unittests stage1 -> Basic function tests, no mocking allowed stage2 -> Mocked tests for specific scenarios/regressions stage3 -> Complex setups for layered products/environments At the moment, these unittests are not updated for avocado, though most should still work with `nosetest` directly. A new set of base classes is defined in tests/sos_tests.py which provide the foundation for actual tests cases. This approach entails new test cases subclassing a base class, such as the new `StageOneReportTest`, and setting the `sos_cmd` class attr to the _options_ for an sos report run. By default `sos report --batch` will be run, and targeted to the test job's directory as a tmpdir. Each sos command will be executed once, and all test_* methods within a test case that subclasses `StageOneReportTest` will be checked against the output of that execution. Note that this diverges from avocado's typical approach where each test_* method is performed against a brand new instance of the class (thus meaning any setup including our sos report run would normally be run fresh). However, after speaking with the avocado devel team, this is still seen as a valid pattern for the framework. The current organizational approach is to separate the tests by component rather than stage. For example. `tests/report_tests/` should hold any report-centric tests, and the `plugin_tests` directory therein should be used for plugin-specific tests. As of this commit, there are basic functionality tests under `tests/report_tests/` and a single plugin test under `tests/report_tests/plugin_tests/` to act as a POC. Further, there is a `tests/vendor_tests/` directory for organizing vendor-specific bug/feature tests that are not covered by the generic project-wide tests. A POC test from RHBZ1928628 is available with this commit. Note that in order for these tests to be run properly _without_ installing the current branch to the local system, you will need to run the following command: `PYTHONPATH=tests/ avocado run -t stageone tests/` Related: #2431 Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>