vyos-cloud-init.git/cloudinit/helpers.py, branch rolling

Adopt Black and isort (SC-700) (#1157)

2021-12-16T02:16:38+00:00

Applied Black and isort, fixed any linting issues, updated tox.ini and CI.

Fix unpickle for source paths missing run_dir (#863)

2021-04-12T16:22:22+00:00

On the datasource class, we require the use of paths.run_dir to perform some operations. On older cloud-init version, the Paths class does not have the run_dir attribute. To fix that, we are now manually adding that attribute in the Paths object if doesn't exist in the unpickle operation. LP: #1899299

openstack: read the dynamic metadata group vendor_data2.json (#777)

2021-02-05T16:11:14+00:00

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

templater: drop Jinja Python 2 compatibility shim (#353)

2020-05-15T03:22:27+00:00

cloudinit: replace "from six import X" imports (except in util.py) (#183)

2020-01-31T15:15:31+00:00

cli: add cloud-init query subcommand to query instance metadata

2018-09-25T21:59:16+00:00

Cloud-init caches any cloud metadata crawled during boot in the file /run/cloud-init/instance-data.json. Cloud-init also standardizes some of that metadata across all clouds. The command 'cloud-init query' surfaces a simple CLI to query or format any cached instance metadata so that scripts or end-users do not have to write tools to crawl metadata themselves. Since 'cloud-init query' is runnable by non-root users, redact any sensitive data from instance-data.json and provide a root-readable unredacted instance-data-sensitive.json. Datasources can now define a sensitive_metadata_keys tuple which will redact any matching keys which could contain passwords or credentials from instance-data.json. Also add the following standardized 'v1' instance-data.json keys: - user_data: The base64encoded user-data provided at instance launch - vendor_data: Any vendor_data provided to the instance at launch - underscore_delimited versions of existing hyphenated keys: instance_id, local_hostname, availability_zone, cloud_name

user-data: jinja template to render instance-data.json in cloud-config

2018-09-11T17:31:46+00:00

Allow users to provide '## template: jinja' as the first line or their #cloud-config or custom script user-data parts. When this header exists, the cloud-config or script will be rendered as a jinja template. All instance metadata keys and values present in /run/cloud-init/instance-data.json will be available as jinja variables for the template. This means any cloud-config module or script can reference any standardized instance data in templates and scripts. Additionally, any standardized instance-data.json keys scoped below a '' key will be promoted as a top-level key for ease of reference in templates. This means that '{{ local_hostname }}' is the same as using the latest '{{ v#.local_hostname }}'. Since instance-data is written to /run/cloud-init/instance-data.json, make sure it is persisted across reboots when the cached datasource opject is reloaded. LP: #1791781

cc_landscape & cc_puppet: Fix six.StringIO use in writing configs

2017-08-23T19:24:38+00:00

Both landscape and puppet modules had issues with the way they wrote /etc/landscape/client.conf or /etc/puppet/puppet.conf in either python3 or python2. This branch adds initial unit tests for both modules which will get better exercise under both python2 and python3. The unit tests shed light on a few issues: - In the cc_landscape module py3 can't provide six.StringIO content to ConfigParser.write, so we need to use six.BytesIO instead - In the cc_puppet module, python <= 2.7 doesn't support using six.StringIO as a context manager, so we drop the context manager fanciness and directly set outputstream = StringIO(). - The docstring in cc_puppet is fixed to document the 'conf' sub-key requiring valid puppet section names for each key-value list. LP: #1699282 LP: #1710932

pylint: fix all logging warnings

2017-04-21T14:14:47+00:00

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.

Move warning functionality to cloudinit/warnings.py

2017-03-03T06:30:15+00:00

This moves the warning code that was added specifically for EC2 into a generic path at cloudinit/warnings.py. It also adds support for writing warning files into the warnings directory to be shown by Z99-cloudinit-warnings.sh.