summaryrefslogtreecommitdiff
path: root/cloudinit/analyze/tests/test_boot.py
AgeCommit message (Collapse)Author
2021-12-03Reorganize unit test locations under tests/unittests (#1126)Brett Holman
This attempts to standardize unit test file location under test/unittests/ such that any source file located at cloudinit/path/to/file.py may have a corresponding unit test file at test/unittests/path/to/test_file.py. Noteworthy Comments: ==================== Four different duplicate test files existed: test_{gpg,util,cc_mounts,cc_resolv_conf}.py Each of these duplicate file pairs has been merged together. This is a break in git history for these files. The test suite appears to have a dependency on test order. Changing test order causes some tests to fail. This should be rectified, but for now some tests have been modified in tests/unittests/config/test_set_passwords.py. A helper class name starts with "Test" which causes pytest to try executing it as a test case, which then throws warnings "due to Class having __init__()". Silence by changing the name of the class. # helpers.py is imported in many test files, import paths change cloudinit/tests/helpers.py -> tests/unittests/helpers.py # Move directories: cloudinit/distros/tests -> tests/unittests/distros cloudinit/cmd/devel/tests -> tests/unittests/cmd/devel cloudinit/cmd/tests -> tests/unittests/cmd/ cloudinit/sources/helpers/tests -> tests/unittests/sources/helpers cloudinit/sources/tests -> tests/unittests/sources cloudinit/net/tests -> tests/unittests/net cloudinit/config/tests -> tests/unittests/config cloudinit/analyze/tests/ -> tests/unittests/analyze/ # Standardize tests already in tests/unittests/ test_datasource -> sources test_distros -> distros test_vmware -> sources/vmware test_handler -> config # this contains cloudconfig module tests test_runs -> runs
2021-11-22testing: monkeypatch system_info call in unit tests (SC-533) (#1117)James Falcon
testing: monkeypatch system_info call in unit tests system_info can make calls that read or write from the filesystem, which should require special mocking. It is also decorated with 'lru_cache', which means test authors often don't realize they need to be mocking. Also, we don't actually want the results from the user's local machine, so monkeypatching it across all tests should be reasonable. Additionally, moved some of 'system_info` into a helper function to reduce the surface area of the monkeypatch, added tests for the new function (and fixed a bug as a result), and removed related mocks that should be no longer needed.
2020-06-08Move subp into its own module. (#416)Scott Moser
This was painful, but it finishes a TODO from cloudinit/subp.py. It moves the following from util to subp: ProcessExecutionError subp which target_path I moved subp_blob_in_tempfile into cc_chef, which is its only caller. That saved us from having to deal with it using write_file and temp_utils from subp (which does not import any cloudinit things now). It is arguable that 'target_path' could be moved to a 'path_utils' or something, but in order to use it from subp and also from utils, we had to get it out of utils.
2020-01-08Make tests work with Python 3.8 (#139)Conrad Hoffmann
* Make DistroChecker test work with Python 3.8 In Python 3.8, `platform.linux_distribution` has been removed. This was anticipated, and the cloud-init code uses its own `util.get_linux_distro` instead, which works fine w/o `platform.linux_distribution`. However, these tests still try to mock the platform function, which fails if it doesn't exist (Python 3.8). Instead, mock the new function here, as this is a test for code that depends on it rather than the function itself. * Make GetLinuxDistro tests work with Python 3.8 In Python 3.8, `platform.dist` was removed, so allow mock to create the function by setting `create=True`. * Make linter happy in Python 3.8 Suppress E1101(no-member) as this function was removed.
2019-07-15Cloud-init analyze module: Added ability to analyze boot events.Sam Gilson
This branch introduces a new command line feature for cloud-init. Currently, the cloud-init module has the capability to analyze events in cloud-init.log in three ways: 'show', 'blame', 'dump'. These changes add a fourth capability, called 'boot'. Running the command 'cloud-init analyze boot' will provide the user three timestamps. 1) Timestamp for when the kernel starts initializing. 2) Timestamp for when the kernel finishes its initialization. 3) Timestamp for when systemd activates cloud-init. This feature enables cloud-init users to analyze different boot phases. This would aid in debugging performance issues related to cloud-init startup or tracking regression.