(mirror of https://github.com/vyos/vyos-cloud-init.git) https://git.amelek.net/vyos/vyos-cloud-init.git/atom?h=cla 2022-01-10T22:56:29+00:00 2022-01-10T22:56:29+00:00 James Falcon james.falcon@canonical.com 2022-01-10T22:56:29+00:00 urn:sha1:dc1aabfca851e520693c05322f724bd102c76364 Includes: - Update tox.ini and .travis.yml accordingly - Cleanup tox.ini with new tox syntax and cloud-init dependencies - Update documentation accordingly - Replace/remove xenial references where additional testing isn't required - Remove xenial checks in integration tests - Replace yield_fixture with fixture in pytest tests Sections of code commented with lines like "Remove when Xenial is no longer supported" still exist as they're require additional testing. 2021-12-16T02:16:38+00:00 James Falcon james.falcon@canonical.com 2021-12-16T02:16:38+00:00 urn:sha1:bae9b11da9ed7dd0b16fe5adeaf4774b7cc628cf Applied Black and isort, fixed any linting issues, updated tox.ini and CI. 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-11T19:30:59+00:00 Chad Smith chad.smith@canonical.com 2021-11-11T19:30:59+00:00 urn:sha1:918d69a02ec9cb891a5bc987bdce783802b1a743 On Bionic and Xenial, pycloudlib sets user.vendor-data config in lxd to ensure that lxd-agent is setup on those images. Adapt the lxd_discovery integration test to assert the appropriate user.vendor-data config key exists if we are on xenial or bionic. Also add assertions that /var/lib/cloud/nocloud-net/meta-data still exists in the images because we want NoCloud to be a viable fallback datasource if LXD config security.lxddev = false or LXD datasource discovery encountered an unexpected error. 2021-11-02T16:11:26+00:00 James Falcon james.falcon@canonical.com 2021-11-02T16:11:26+00:00 urn:sha1:d54e23bf61bb61af9aef3b30f41084d93961b7e3 In our integration tests, a few tests were modifying the environment and then calling 'install_new_cloud_init'. This is problematic because it updates the environment for all future tests. Other instances of 'install_new_cloud_init' aren't problematic because they aren't modifying the underlying environment. 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-10-07T16:27:36+00:00 James Falcon james.falcon@canonical.com 2021-10-07T16:27:36+00:00 urn:sha1:9c147e8341e287366790e60658f646cdcc59bef2 In #919 (81299de), we refactored some of the code used to bring up networks across distros. Previously, the call to bring up network interfaces during 'init' stage unintentionally resulted in a no-op such that network interfaces were NEVER brought up by cloud-init, even if new network interfaces were found after crawling the metadata. The code was altered to bring up these discovered network interfaces. On ubuntu, this results in a 'netplan apply' call during 'init' stage for any ubuntu-based distro on a datasource that has a NETWORK dependency. On GCE, this additional 'netplan apply' conflicts with the google-guest-agent service, resulting in an instance that can no be connected to. This commit adds a 'disable_network_activation' option that can be enabled in /etc/cloud.cfg to disable the activation of network interfaces in 'init' stage. LP: #1938299