(mirror of https://github.com/marekm72/vyos-cloud-init.git) https://git.amelek.net/marekm72/vyos-cloud-init.git/atom?h=equuleus 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"] }} 2021-11-18T22:08:33+00:00 Chad Smith chad.smith@canonical.com 2021-11-18T22:08:33+00:00 urn:sha1:7ebf04e3a1920b451a0bb4b6302706a2b6632d6b LXD now adds cloud-init scoped configuration keys network-config, user-data and vendor-data. The existing user.user-data, user.vendor-data, user.network-config and meta-data will be deprecated in newer LXD. cloud-init will prefer LXD config keys cloud-init.* keys above user.* keys even if both are present. Warnings will be emitted for ignored user.* keys if cloud-init.* overrides are present. Expectation is that the configuration user.network-config, user.meta-data, user.user-data and user.vendor-data* keys should not be present at the same time as the comparable cloud-init.* keys. 2021-11-01T20:43:05+00:00 Chad Smith chad.smith@canonical.com 2021-11-01T20:43:05+00:00 urn:sha1:773765346ba543987aa64a1119fa760f0b1cbb6f Add DataSourceLXD which knows how to talk to the dev-lxd socket to obtain all instance metadata API: https://linuxcontainers.org/lxd/docs/master/dev-lxd. This first branch is to deliver feature parity with the existing NoCloud datasource which is currently used to intialize LXC instances on first boot. Introduce a SocketConnectionPool and LXDSocketAdapter to support performing HTTP GETs on the following routes which are surfaced by the LXD host to all containers: http://unix.socket/1.0/meta-data http://unix.socket/1.0/config/user.user-data http://unix.socket/1.0/config/user.network-config http://unix.socket/1.0/config/user.vendor-data These 4 routes minimally replace the static content provided in the following nocloud-net seed files: /var/lib/cloud/nocloud-net/{meta-data,vendor-data,user-data,network-config} The intent of this commit is to set a foundation for LXD socket communication that will allow us to build network hot-plug features by eventually consuming LXD's websocket upgrade route 1.0/events to react to network, meta-data and user-data config changes over time. In the event that no custom network-config is provided, default to the same network-config definition provided by LXD to the NoCloud network-config seed file. Supplemental features above NoCloud datasource: surface all custom instance data config keys via cloud-init query ds which aids in discoverability of features/tags/labels as well as conditional #cloud-config jinja templates operations based on custom config options. TBD: better cloud-init query support for dot-delimited keys 2021-09-21T04:53:05+00:00 vteratipally 67723486+vteratipally@users.noreply.github.com 2021-09-21T04:53:05+00:00 urn:sha1:e27c30748e88409b1646a552f994edf9ed9d017e Add retries to DatasourceGCE when connecting to GCE. Sometimes when the trying to fetch the metadata, cloud-init fails and the fallback datasource NoCloud is used which is not expected. Add retries to ensure loading of the data source. 2021-09-17T18:04:07+00:00 James Falcon therealfalcon@gmail.com 2021-09-17T18:04:07+00:00 urn:sha1:612e39087aee3b1242765e7c4f463f54a6ebd723 Add connectivity_url to Oracle's EphemeralDHCPv4 On bionic, when trying to bring up the EphemeralDHCPv4, it's possible that we already have a route defined, which will result in an error when trying to add the DHCP route. Use the connectivity_url to check if we can reach the metadata service, and if so, skip the EphemeralDHCPv4. The has_url_connectivity function has also been modified to take a dict of kwargs to send to readurl. LP: #1939603 2021-05-13T17:55:41+00:00 James Falcon TheRealFalcon@users.noreply.github.com 2021-05-13T17:55:41+00:00 urn:sha1:864346999702e6b2b8bf7e6244a6608bcead72a5 Control is currently limited to boot events, though this should allow us to more easily incorporate HOTPLUG support. Disabling 'instance-first-boot' is not supported as we apply networking config too early in boot to have processed userdata (along with the fact that this would be a pretty big foot-gun). The concept of update events on datasource has been split into supported update events and default update events. Defaults will be used if there is no user-defined update events, but user-defined events won't be supplied if they aren't supported. When applying the networking config, we now check to see if the event is supported by the datasource as well as if it is enabled. Configuration looks like: updates: network: when: ['boot'] 2021-03-08T17:50:57+00:00 Daniel Watkins oddbloke@ubuntu.com 2021-03-08T17:50:57+00:00 urn:sha1:121bc04cdf0e6732fe143b7419131dc250c13384 `get_interfaces` is used to in two ways, broadly: firstly, to determine the available interfaces when converting cloud network configuration formats to cloud-init's network configuration formats; and, secondly, to ensure that any interfaces which are specified in network configuration are (a) available, and (b) named correctly. The first of these is unaffected by this commit, as no clouds support Open vSwitch configuration in their network configuration formats. For the second, we check that MAC addresses of physical devices are unique. In some OVS configurations, there are OVS-created devices which have duplicate MAC addresses, either with each other or with physical devices. As these interfaces are created by OVS, we can be confident that (a) they will be available when appropriate, and (b) that OVS will name them correctly. As such, this commit excludes any OVS-internal interfaces from the set of interfaces returned by `get_interfaces`. LP: #1912844 2020-11-02T20:41:11+00:00 Scott Moser smoser@brickies.net 2020-11-02T20:41:11+00:00 urn:sha1:0af1ff1eaf593c325b4f53181a572110eb016c50 This just separates the reading of dmi values into its own file. Some things of note: * left import of util in dmi.py only for 'is_container' It'd be good if is_container was not in util. * just the use of 'util.is_x86' to dmi.py * open() is used directly rather than load_file. 2020-08-14T15:37:33+00:00 Daniel Watkins oddbloke@ubuntu.com 2020-08-14T15:37:33+00:00 urn:sha1:2d3533b59c7bf00affbda9c2c94fb5f214ffcb11