(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. 2020-08-25T15:21:18+00:00 Paride Legovini paride.legovini@canonical.com 2020-08-25T15:21:18+00:00 urn:sha1:07104504ab5b30efd2d1f7a8c36effe18b8e5fe0 Changes: tox: bump the pylint version to 2.6.0 in the default run Fix pylint 2.6.0 W0707 warnings (raise-missing-from) 2020-05-14T15:25:02+00:00 Daniel Watkins oddbloke@ubuntu.com 2020-05-14T15:25:02+00:00 urn:sha1:4261ae538563d262bc76b8c55f7cc0c8abb14b00 We live in the future now. 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 2018-10-09T21:46:35+00:00 Chad Smith chad.smith@canonical.com 2018-10-09T21:46:35+00:00 urn:sha1:f0bc02d7e221c9aa5982b267739481420c761ead Add the following instance-data.json standardized keys: * v1._beta_keys: List any v1 keys in beta development, e.g. ['subplatform']. * v1.public_ssh_keys: List of any cloud-provided ssh keys for the instance. * v1.platform: String representing the cloud platform api supporting the datasource. For example: 'ec2' for aws, aliyun and brightbox cloud names. * v1.subplatform: String with more details about the source of the metadata consumed. For example, metadata uri, config drive device path or seed directory. To support the new platform and subplatform standardized instance-data, DataSource and its subclasses grew platform and subplatform attributes. The platform attribute defaults to the lowercase string datasource name at self.dsname. This method is overridden in NoCloud, Ec2 and ConfigDrive datasources. The subplatform attribute calls a _get_subplatform method which will return a string containing a simple slug for subplatform type such as metadata, seed-dir or config-drive followed by a detailed uri, device or directory path where the datasource consumed its configuration. As part of this work, DatasourceEC2 methods _get_data and _crawl_metadata have been refactored for a few reasons: - crawl_metadata is now a read-only operation, persisting no attributes on the datasource instance and returns a dictionary of consumed metadata. - crawl_metadata now closely represents the raw stucture of the ec2 metadata consumed, so that end-users can leverage public ec2 metadata documentation where possible. - crawl_metadata adds a '_metadata_api_version' key to the crawled ds.metadata to advertise what version of EC2's api was consumed by cloud-init. - _get_data now does all the processing of crawl_metadata and saves datasource instance attributes userdata_raw, metadata etc. Additional drive-bys: * unit test rework for test_altcloud and test_azure to simplify mocks and make use of existing util and test_helpers functions. 2018-05-17T20:59:54+00:00 Scott Moser smoser@ubuntu.com 2018-05-17T20:59:54+00:00 urn:sha1:30e730f7ca111487d243ba9f40c66df6d7a49953 The result of a read_file_or_url on a file and on a url would differ in behavior. str(UrlResponse) would return UrlResponse.contents.decode('utf-8') while str(FileResponse) would return str(FileResponse.contents) The difference being "b'foo'" versus "foo". As part of the general goal of cleaning util, move read_file_or_url into url_helper. 2018-04-20T03:30:08+00:00 Scott Moser smoser@ubuntu.com 2018-04-20T03:30:08+00:00 urn:sha1:1081962eacf2814fea6f4fa3255c530de14e4a24 This enables warnings produced by pylint for unused variables (W0612), and fixes the existing errors. 2018-01-10T20:53:17+00:00 Scott Moser smoser@ubuntu.com 2018-01-10T20:53:17+00:00 urn:sha1:5f550420d2ed9d9ef024293f33d33f0f2fc04ee5 This stores a hash of the OAuth tokens as an 'id' for the maas datasource. Since new instances get new tokens created and those tokens are written by curtin into datasource system config this will provide a way to identify a new "instance" (install). LP: #1712680 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-04-21T14:14:47+00:00 Joshua Powers josh.powers@canonical.com 2017-04-06T18:14:29+00:00 urn:sha1:5afe4cd0797a12d07ea19b9715b720d47bdea401 This will change all instances of LOG.warn to LOG.warning as warn is now a deprecated method. It will also make sure any logging uses lazy logging by passing string format arguments as function parameters.