| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
pylint for the following rules applied
* C0411: wrong-import-order
* R0912: too-many-branches
* R0914: too-many-locals
* R1725: super-with-arguments
* E1101: no-member
Resolves: #3597
Signed-off-by: Arif Ali <arif.ali@canonical.com>
|
| |
|
|
| |
Signed-off-by: Arif Ali <arif.ali@canonical.com>
|
| |
|
|
| |
Signed-off-by: Arif Ali <arif.ali@canonical.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consolidate testing, so that things can be run from CLI, CI and
various other means in a consistent way by using tox.
* Updated all the flake8 tests in the tests folder.
* Added pylint as a neutral test so that we can work on this in stages
and have some collaboration on what we test and don't
* The tox tests for unit, stageone, stagetwo testing makes is easier
for users to know how to run tests, and not have to do things
manually
* Using tox for CI doesn't make sense, as that will create virtual
envs and will disregard system/snap based python modules so may not
work
Signed-off-by: Arif Ali <arif.ali@canonical.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Avocado tests generate netdevs by listing /sys/class/net which can
contain also bonding_masters that does not refer to any netdev. In such
a case, the test case fails.
Resolves: #3176
Closes: #3178
Signed-off-by: Pavel Moravec <pmoravec@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Historically, journal sizes have been limited to the *higher* of 100MB
or `--log-size`. While this had the benefit of potentially controlling
both logs and journals with the same option, it was not immediately
intuitive to end users and downright prevented collecting less than
100MB of journals.
Address this by separating journal size limiting from `--log-size` by
adding a new `--journal-size` option (default 100). This will allow
users to individually control journal sizes without any "gotcha"
scenarios with relation to general log size limiting.
Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, mocked files were kept under the `tests/test_data/`
directory and generally mimic'd the file location they would be
temporarily copied to during the execution of their relevant tests.
This has a few maintainability drawbacks, and the handling of the
`files` attribute for test cases as either strings or tuples is at best
confusing.
Improve on this by instead making the `files` references relative to
where the test case file is written. This enables easier maintenance by
keeping all test requirements closer together, rather than spread across
the repo. As such, the `files` attribute now requires a list of tuples,
taking the form `(relative_src, absolute_dest)`. Additionally, fake
plugins for tests that need them to artificially test a specific
criteria should also be included in the test's subdir now.
Along with this change, move several StageTwo tests to their own subdirs
that now contain both the test cases and the needed files for mocking.
This should be the new design pattern going forward - if a test needs to
mock files of any kind, put it in a new subdirectory (and if it doesn't
need to mock files, continue to keep it in the relevant directory within
the test suite).
Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After all plugins have run, sos will now generate a "tag summary" and
add it to the report section of the manifest. This summary will be a
json-formatted entry that details all collections within the report that
have any tag associated with them at all. This should allow for easier
parsing of the manifest by analyzers such as Red Hat Insights.
As part of this change, commands will no longer be automatically tagged
with the name of the binary used in the command collection.
Additionally, manual collections performed by a plugin's `collect()`
method will now be recorded in the manifest in the same manner as file
and command output collections.
Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
| |
Adds a new test to the networking plugin test to ensure we iterate
correctly over network devices.
|
| |
|
|
|
|
|
|
|
| |
Removes catalog entries from the journal collection for `this` and
`last` boot collections.
Closes: #2132
Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
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>
|
