(mirror of https://github.com/vyos/vyos-cloud-init.git) https://git.amelek.net/vyos/vyos-cloud-init.git/atom?h=rolling 2021-12-16T02:16:38+00:00 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-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-08-10T02:24:07+00:00 Andrew Kutz 101085+akutz@users.noreply.github.com 2021-08-10T02:24:07+00:00 urn:sha1:8b4a9bc7b81e61943af873bad92e2133f8275b0b This patch finally introduces the Cloud-Init Datasource for VMware GuestInfo as a part of cloud-init proper. This datasource has existed since 2018, and rapidly became the de facto datasource for developers working with Packer, Terraform, for projects like kube-image-builder, and the de jure datasource for Photon OS. The major change to the datasource from its previous incarnation is the name. Now named DatasourceVMware, this new version of the datasource will allow multiple transport types in addition to GuestInfo keys. This datasource includes several unique features developed to address real-world situations: * Support for reading any key (metadata, userdata, vendordata) both from the guestinfo table when running on a VM in vSphere as well as from an environment variable when running inside of a container, useful for rapid dev/test. * Allows booting with DHCP while still providing full participation in Cloud-Init instance data and Jinja queries. The netifaces library provides the ability to inspect the network after it is online, and the runtime network configuration is then merged into the existing metadata and persisted to disk. * Advertises the local_ipv4 and local_ipv6 addresses via guestinfo as well. This is useful as Guest Tools is not always able to identify what would be considered the local address. The primary author and current steward of this datasource spoke at Cloud-Init Con 2020 where there was interest in contributing this datasource to the Cloud-Init codebase. The datasource currently lives in its own GitHub repository at https://github.com/vmware/cloud-init-vmware-guestinfo. Once the datasource is merged into Cloud-Init, the old repository will be deprecated. 2021-04-13T18:15:34+00:00 David Dymko dymkod@gmail.com 2021-04-13T18:15:34+00:00 urn:sha1:0ae0b1d4336acdcab12bd49e9bddb46922fb19c7 This PR adds in support so that cloud-init can run on instances deployed on Vultr cloud. This was originally brought up in #628. Co-authored-by: Eric Benner <ebenner@vultr.com> 2021-02-08T15:24:36+00:00 Antti Myyrä antti.myyra@gmail.com 2021-02-08T15:24:36+00:00 urn:sha1:0497c7b1f752c7011006b36f9c07ac141c0bb3c2 New datasource utilizing UpCloud metadata API, including relevant unit tests and documentation. 2021-02-05T16:11:14+00:00 Andrew Bogott Andrewbogott@gmail.com 2021-02-05T16:11:14+00:00 urn:sha1:3cebe0df1e002bd85c8aa78e89f0ca507c17195a Add support for openstack's dynamic vendor data, which appears under openstack/latest/vendor_data2.json This adds vendor_data2 to all pathways; it should be a no-op for non-OpenStack providers. LP: #1841104 2019-12-18T14:53:49+00:00 Adam Dobrawy naczelnik@jawnosc.tk 2019-12-17T01:04:10+00:00 urn:sha1:fa0c9e37d98b16f2404e6b4c61e1ae4df7f2f15b 2019-08-08T17:09:57+00:00 Chris Glass christopher.glass@exoscale.ch 2019-08-08T17:09:57+00:00 urn:sha1:4dfed67d0e82970f8717d0b524c593962698ca4f - dsidentify switches to the new Exoscale datasource on matching DMI name - New Exoscale datasource added Signed-off-by: Mathieu Corbin <mathieu.corbin@exoscale.ch> 2018-09-17T13:07:39+00:00 Robert Schweikert rjschwei@suse.com 2018-09-17T13:07:39+00:00 urn:sha1:c714651c1988a17f457426de63cdb8514d5a81b4 If the user has removed the default configuration file or does not set the syslog_fix_perms config option the user still ends up with a warning on SUSE distributions. Add root:root to the default builtin config. 2018-08-17T20:25:31+00:00 Scott Moser smoser@ubuntu.com 2018-08-17T20:25:31+00:00 urn:sha1:aaffd59431fe05932a66016db941fe197c4e7620 This adds a Oracle specific datasource that functions with OCI. It is a simplified version of the OpenStack metadata server with support for vendor-data. It does not support the OCI-C (classic) platform. Also here is a move of BrokenMetadata to common 'sources' as this was the third occurrence of that class.