(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-10-18T16:26:48+00:00 Olivier Lemasle o.lemasle@gmail.com 2021-10-18T16:26:48+00:00 urn:sha1:62c2a56e053dd70638ef3421ffbfbc0b81356691 CloudStack DNS resolution should be done against the DNS search domain (with the final dot, DNS resolution does not work with e.g. Fedora 34) LP: #1942232 2020-06-08T16:49:12+00:00 Scott Moser smoser@brickies.net 2020-06-08T16:49:12+00:00 urn:sha1:3c551f6ebc12f7729a2755c89b19b9000e27cc88 This was painful, but it finishes a TODO from cloudinit/subp.py. It moves the following from util to subp: ProcessExecutionError subp which target_path I moved subp_blob_in_tempfile into cc_chef, which is its only caller. That saved us from having to deal with it using write_file and temp_utils from subp (which does not import any cloudinit things now). It is arguable that 'target_path' could be moved to a 'path_utils' or something, but in order to use it from subp and also from utils, we had to get it out of utils. 2019-11-23T03:05:44+00:00 Ryan Harper ryan.harper@canonical.com 2019-11-23T03:05:44+00:00 urn:sha1:4bc399e0cd0b7e9177f948aecd49f6b8323ff30b * ec2: Add support for AWS IMDS v2 (session-oriented) AWS now supports a new version of fetching Instance Metadata[1]. Update cloud-init's ec2 utility functions and update ec2 derived datasources accordingly. For DataSourceEc2 (versus ec2-look-alikes) cloud-init will issue the PUT request to obtain an API token for the maximum lifetime and then all subsequent interactions with the IMDS will include the token in the header. If the API token endpoint is unreachable on Ec2 platform, log a warning and fallback to using IMDS v1 and which does not use session tokens when communicating with the Instance metadata service. We handle read errors, typically seen if the IMDS is beyond one etwork hop (IMDSv2 responses have a ttl=1), by setting the api token to a disabled value and then using IMDSv1 paths. To support token-based headers, ec2_utils functions were updated to support custom headers_cb and exception_cb callback functions so Ec2 could store, or refresh API tokens in the event of token becoming stale. [1] https://docs.aws.amazon.com/AWSEC2/latest/ \ UserGuide/ec2-instance-metadata.html \ #instance-metadata-v2-how-it-works 2019-11-12T20:42:41+00:00 Joshua Hügli joshua@trafficteam.ch 2019-11-12T20:42:41+00:00 urn:sha1:9662a8791e53bac40a3a37aa3f5bee3076f7d447 2019-05-08T15:14:31+00:00 Daniel Watkins daniel.watkins@canonical.com 2019-05-08T15:14:31+00:00 urn:sha1:9aa97cfc73b31dc548a240e5f4bd1ef41861cc4d 2018-05-23T22:08:43+00:00 Chad Smith chad.smith@canonical.com 2018-05-23T22:08:43+00:00 urn:sha1:cd1de5f47ab6b82f2c6fd61a5f6681f33b3e5705 Network has not yet been configured in the init-local stage so the openstack datasource will use dhcp-client to temporarily obtain an ipv4 address and query the metadata service at http://169.254.169.254 to get network_data.json configuration. If present, the datasource will return network_config version 1 config based on that network_data.json content. Previously OpenStack datasource only setup dhcp on the fallback interface so this represents a change in behavior to react to the full config provided by openstack. Also significant to OpenStack is the separation of a _crawl_data operation from get_data(). crawl_data walks the available metadata services and returns a dict of discovered content. get_data consumes the crawled_data,  caches it in the datasource and reacts to that data. /run/cloud-init/instance-data.json now published network_data.json or ec2_metadata key if that data is present on any datasource. The main reasons for the separation of crawl from get_data:  * Enable performance metrics of cloud-init's metadata crawls on each  * Enable cloud-init modules and scripts to query and consume metadata    content which may have updated/changed after cloud-init's initial cache    during instance boot. (Think hotplug) Also generalize common logic to base DataSource class/module:  * Move to a common UNSET variable up into base datasource module fix EC2,    ConfigDrive, OpenStack, SmartOS to use the global.  * Drop get_url_settings from Ec2, CloudStack and OpenStack and generalize    DataSource.get_url_params(). Allow subclasses to override url_max_wait,    url_timeout and url_retries params.  * Rename get_network_metadata bool to perform_dhcp_setup as it designates    whether EphemeralDHCPv4 setup is required before crawling metadata. LP: #1749717 2017-12-05T23:42:35+00:00 Chad Smith chad.smith@canonical.com 2017-12-05T23:42:35+00:00 urn:sha1:0cf6db3617e0cebeb89c4809396f84360827e96c Each DataSource subclass must define its own get_data method. This branch formalizes our DataSource class to require that subclasses define an explicit dsname for sourcing cloud-config datasource configuration. Subclasses must also override the _get_data method or a NotImplementedError is raised. The branch also writes /run/cloud-init/instance-data.json. This file contains all meta-data, user-data and vendor-data and a standardized set of metadata keys in a json blob which other utilities with root-access could make use of. Because some meta-data or user-data is potentially sensitive the file is only readable by root. Generally most metadata content types should be json serializable. If specific keys or values are not serializable, those specific values will be base64encoded and the key path will be listed under the top-level key 'base64-encoded-keys' in instance-data.json. If json writing fails due to other TypeErrors or UnicodeDecodeErrors, a warning log will be emitted to /var/log/cloud-init.log and no instance-data.json will be created. 2017-10-03T12:59:43+00:00 Dimitri John Ledkov xnox@ubuntu.com 2017-09-30T04:00:18+00:00 urn:sha1:9d2a87dc386b7aed1a8243d599676e78ed358749 Systems that used systemd-networkd's dhcp client would not be able to get information on the Azure endpoint (placed in Option 245) or the CloudStack server (in 'server_address'). The change here supports reading these files in /run/systemd/netif/leases. The files declare that "This is private data. Do not parse.", but at this point we do not have another option. LP: #1718029 2017-09-15T19:38:56+00:00 Scott Moser smoser@brickies.net 2017-09-15T19:37:55+00:00 urn:sha1:da1db792b2721d94ef85df8c136e78012c49c6e5 A regression in 'get_latest_lease' made it ignore files starting with 'dhclient-' rather than just 'dhclient.'. The fix here is to allow those files to be considered. There is a lot more we could do here to better ensure that we pick the most recent lease, but this change fixes the regression. LP: #1717147