(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-12-03T04:25:43+00:00 Chad Smith chad.smith@canonical.com 2021-12-03T04:25:43+00:00 urn:sha1:0fe96a44cde48cc688afe75beb8fd126c8892b8c Allow #cloud-config and cloud-init query to use underscore-delimited "jinja-safe" key aliases for any instance-data.json keys containing jinja operator characters. This provides a means to use Jinja's dot-notation instead of square brackets and quoting to reference "unsafe" obtain attribute names. Support for these aliased keys is available to both #cloud-config user-data and `cloud-init query`. For example #cloud-config alias access can look like: {{ ds.config.user_network_config }} - instead of - {{ ds.config["user.network-config"] }} 2020-08-24T16:13:52+00:00 Chad Smith chad.smith@canonical.com 2020-08-24T16:13:52+00:00 urn:sha1:c0450c02b25fe037c702e9bb145fbbaa28a165b1 2020-08-20T21:51:35+00:00 Chad Smith chad.smith@canonical.com 2020-08-20T21:51:35+00:00 urn:sha1:747723a42c98fa13080ea31127e289e7b826046f cloud-init query tries to directly load and decode raw user-data from /var/lib/cloud/instance/user-data.txt. This results in UnicodeDecodeErrors on some platforms which provide compressed content. Avoid UnicodeDecoderErrors when parsing compressed user-data at /var/lib/cloud/instance/user-data.txt. LP: #1889938 2020-06-02T15:24:29+00:00 Joshua Powers josh.powers@canonical.com 2020-06-02T15:24:29+00:00 urn:sha1:5f7825e22241423322dbe628de1b00289cf34114 Remove extra spaces after a ',' 2020-01-31T15:15:31+00:00 Daniel Watkins oddbloke@ubuntu.com 2020-01-31T15:15:31+00:00 urn:sha1:1bb1896ec900622e02c1ffb59db4d3f2df4a964d 2019-12-16T15:08:25+00:00 Joshua Powers josh.powers@canonical.com 2019-12-16T15:08:25+00:00 urn:sha1:22054368db4cb83074860f8114e61a8fb183489d The query command checks the user's uid when running and takes two different code paths. As a normal user is returns fake data, that these tests were expecting. As a root user, the actual user and vendor data files are ready. LP: #1856096 2018-10-30T20:02:38+00:00 Chad Smith chad.smith@canonical.com 2018-10-30T20:02:38+00:00 urn:sha1:d74d3f0ff5c8d453f626b113f4e6065322f822fa Emit a permissions error instead of "Missing instance-data.json" when non-root user doesn't have read-permission on /run/cloud-init/instance-data.json 2018-10-26T03:49:57+00:00 Chad Smith chad.smith@canonical.com 2018-10-26T03:49:57+00:00 urn:sha1:dc0be9c56f78537f1808934d26f5aa0868ae7842 On cloud-init upgrade path from 18.3 to 18.4 cloud-init changed how instance-data is written. Cloud-init changes instance-data.json from root read-only to redacted world-readable content, and provided a separate unredacted instance-data-sensitive.json which is read-only root. Since instance-data is only rewritten from cache on reboot, the query and render tools needed fallback to use the 'old' instance-data.json if the new sensitive file isn't yet present. This avoids error messages from tools about an absebt /run/instance-data-sensitive.json file. LP: #1798189 2018-09-25T21:59:16+00:00 Chad Smith chad.smith@canonical.com 2018-09-25T21:59:16+00:00 urn:sha1:fc4b966ba928b30b1c586407e752e0b51b1031e8 Cloud-init caches any cloud metadata crawled during boot in the file /run/cloud-init/instance-data.json. Cloud-init also standardizes some of that metadata across all clouds. The command 'cloud-init query' surfaces a simple CLI to query or format any cached instance metadata so that scripts or end-users do not have to write tools to crawl metadata themselves. Since 'cloud-init query' is runnable by non-root users, redact any sensitive data from instance-data.json and provide a root-readable unredacted instance-data-sensitive.json. Datasources can now define a sensitive_metadata_keys tuple which will redact any matching keys which could contain passwords or credentials from instance-data.json. Also add the following standardized 'v1' instance-data.json keys:   - user_data: The base64encoded user-data provided at instance launch   - vendor_data: Any vendor_data provided to the instance at launch   - underscore_delimited versions of existing hyphenated keys:     instance_id, local_hostname, availability_zone, cloud_name