vyos-cloud-init.git/cloudinit/cmd/devel, branch crux

ovf: Fix ovf network config generation gateway/routes

2018-12-03T18:43:21+00:00

Move routes under the nic's subnet rather than use top-level ("global") route config ensuring all net renderers will provide the configured route. Also updated cloudinit/cmd/devel/net_convert.py: - Add input type 'vmware-imc' for OVF customization config files - Fix bug when output-type was netplan which invoked netplan generate/apply and attempted to write to /etc/netplan/50-cloud-init.yaml instead of joining with the output directory. LP: #1806103

logs: collect-logs ignore instance-data-sensitive.json on non-root user

2018-11-27T02:09:29+00:00

Since /run/cloud-init/instance-data-sensitive.json is root read-only, ignore this file if non-root user runs collect-logs. If --include-userdata is provided on the command line, exit in error if non-root user attempts this operation. Lastly, update the __main__ to exit based on return value of main. LP: #1805201

query: better error when missing read permission on instance-data

2018-10-30T20:02:38+00:00

Emit a permissions error instead of "Missing instance-data.json" when non-root user doesn't have read-permission on /run/cloud-init/instance-data.json

instance-data: fallback to instance-data.json if sensitive is absent.

2018-10-26T03:49:57+00:00

On cloud-init upgrade path from 18.3 to 18.4 cloud-init changed how instance-data is written. Cloud-init changes instance-data.json from root read-only to redacted world-readable content, and provided a separate unredacted instance-data-sensitive.json which is read-only root. Since instance-data is only rewritten from cache on reboot, the query and render tools needed fallback to use the 'old' instance-data.json if the new sensitive file isn't yet present. This avoids error messages from tools about an absebt /run/instance-data-sensitive.json file. LP: #1798189

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

sysconfig: refactor sysconfig to accept distro specific templates paths

2018-09-05T14:17:16+00:00

Multiple distros use sysconfig format but have different content and paths to certain files. Update distros to specify these template paths in their renderer_configs dictionary.

azure: allow azure to generate network configuration from IMDS per boot.

2018-08-17T20:24:58+00:00

Azure datasource now queries IMDS metadata service for network configuration at link local address http://169.254.169.254/metadata/instance?api-version=2017-12-01. The azure metadata service presents a list of macs and allocated ip addresses associated with this instance. Azure will now also regenerate network configuration on every boot because it subscribes to EventType.BOOT maintenance events as well as the 'first boot' EventType.BOOT_NEW_INSTANCE. For testing add azure-imds --kind to cloud-init devel net_convert tool for debugging IMDS metadata. Also refactor _get_data into 3 discrete methods: - is_platform_viable: check quickly whether the datasource is potentially compatible with the platform on which is is running - crawl_metadata: walk all potential metadata candidates, returning a structured dict of all metadata and userdata. Raise InvalidMetaData on error. - _get_data: call crawl_metadata and process results or error. Cache instance data on class attributes: metadata, userdata_raw etc.

tools: Add 'net-convert' subcommand command to 'cloud-init devel'.

2018-08-06T16:50:51+00:00

Move the tools/net-convert.py to be exposed as part of 'cloud-init devel' subcommands. It can now be called like: $ cloud-init devel net-convert Or, if you just have checked out source (and no cli executable): $ python3 -m cloudinit.cmd.devel.net_convert or $ python3 -m cloudinit.cmd.main devel net-convert

collect-logs: add -v flag, write to stderr, limit journal to single boot.

2018-05-01T18:36:49+00:00

With no output at all from collect-logs, users have been confused on where the output is. By default now, write to stderr what that file is. Also * add '-v' to increase verbosity. With a single -v flag, mention what file/info is being collected. * limit the 'journalctl' collection to this boot (--boot=0). collecting entire journal seems unnecessary and can be huge. * do not fail when collecting files or directories that are not there. LP: #1766335