(mirror of https://github.com/vyos/vyos-cloud-init.git) https://git.amelek.net/vyos/vyos-cloud-init.git/atom?h=rolling 2021-12-03T20:11:46+00:00 2021-12-03T20:11:46+00:00 Brett Holman bholman.devel@gmail.com 2021-12-03T20:11:46+00:00 urn:sha1:039c40f9b3d88ee8158604bb18ca4bf2fb5d5e51 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-22T22:56:41+00:00 James Falcon james.falcon@canonical.com 2021-11-22T22:56:41+00:00 urn:sha1:31daf6670aeeba1d452c70bc0d4d04139652be36 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. 2021-04-23T14:18:05+00:00 Anh Vo anhvo@microsoft.com 2021-04-23T14:18:05+00:00 urn:sha1:d5cca27a56145a5eb3d2ebad6749989b2fb7dcd3 Due to hyper-v implementations, iso ejection is more efficient if performed from within the guest. The code will attempt to perform a best-effort ejection. Failure during ejection will not prevent reporting ready from happening. If iso ejection is successful, later iso ejection from the platform will be a no-op. In the event the iso ejection from the guest fails, iso ejection will still happen at the platform level. 2021-03-25T14:20:10+00:00 Johnson Shi Johnson.Shi@microsoft.com 2021-03-25T14:20:10+00:00 urn:sha1:6ae1145f5e980a47ac2b1ff3afa228a5da3f6e70 Ensure that the Azure helper's http handler sleeps a fixed duration between retry failure attempts. The http handler will sleep a fixed duration between failed attempts regardless of whether the attempt failed due to (1) request timing out or (2) instant failure (no timeout). Due to certain platform issues, the http request to the Azure endpoint may instantly fail without reaching the http timeout duration. Without sleeping a fixed duration in between retry attempts, the http handler will loop through the max retry attempts quickly. This causes the communication between cloud-init and the Azure platform to be less resilient due to the short total duration if there is no sleep in between retries. 2020-11-18T18:02:56+00:00 Johnson Shi Johnson.Shi@microsoft.com 2020-11-18T18:02:56+00:00 urn:sha1:6df0230b1201d6bed8661b19d8f3758797635377 Increase Azure Endpoint HTTP retries to handle occasional platform network blips. Introduce a common method http_with_retries in the azure.py helper, which will serve as the common HTTP request handler for all HTTP requests with the Azure endpoint. This method has builtin retries and reporting diagnostics logic. 2020-11-18T17:34:04+00:00 Johnson Shi Johnson.Shi@microsoft.com 2020-11-18T17:34:04+00:00 urn:sha1:d807df288f8cef29ca74f0b00c326b084e825782 On systems where the Azure datasource is a viable platform for crawling metadata, cloud-init occasionally encounters fatal irrecoverable errors during the crawling of the Azure datasource. When this happens, cloud-init crashes, and Azure VM provisioning would fail. However, instead of failing immediately, the user will continue seeing provisioning for a long time until it times out with "OS Provisioning Timed Out" message. In these situations, cloud-init should report failure to the Azure datasource endpoint indicating provisioning failure. The user will immediately see provisioning terminate, giving them a much better failure experience instead of pointlessly waiting for OS provisioning timeout. 2020-10-16T15:54:38+00:00 Johnson Shi Johnson.Shi@microsoft.com 2020-10-16T15:54:38+00:00 urn:sha1:8766784f4b1d1f9f6a9094e1268e4accb811ea7f DataSourceAzure previously writes the preprovisioning reported ready marker file before it goes through the report ready workflow. On certain VM instances, the marker file is successfully written but then reporting ready fails. Upon rare VM reboots by the platform, cloud-init sees that the report ready marker file already exists. The existence of this marker file tells cloud-init not to report ready again (because it mistakenly assumes that it already reported ready in preprovisioning). In this scenario, cloud-init instead erroneously takes the reprovisioning workflow instead of reporting ready again. 2020-09-10T18:29:54+00:00 Thomas Stringer git@trstringer.com 2020-09-10T18:29:54+00:00 urn:sha1:e56b55452549cb037da0a4165154ffa494e9678a * pull ssh keys from imds first and fall back to ovf if unavailable * refactor log and diagnostic messages * refactor the OpenSSLManager instantiation and certificate usage * fix unit test where exception was being silenced for generate cert * fix tests now that certificate is not always generated * add documentation for ssh key retrieval * add ability to check if http client has security enabled * refactor certificate logic to GoalState 2020-08-13T20:50:07+00:00 Johnson Shi Johnson.Shi@microsoft.com 2020-08-13T20:50:07+00:00 urn:sha1:c3556ae82dfb47d635344fcd78908f003648d6d2 This PR refactors Azure report ready code to include more robust tests and telemetry. 2020-07-13T16:00:32+00:00 Daniel Watkins oddbloke@ubuntu.com 2020-07-13T16:00:32+00:00 urn:sha1:3cec3881062490727c5fff1b16b53f0176f976f0 This includes a fix to a test that had a string concatenation issue, and so was only testing a prefix of what was intended.