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

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

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

cloudinit/cmd/devel/net_convert.py: add missing space (#191)

2020-01-28T15:45:27+00:00

net/netplan: use ipv6-mtu key for specifying ipv6 mtu values

2019-10-24T20:16:47+00:00

netplan introduced an 'info' subcommand which emits yaml describing implemented features that indicate new or changed fields and values in the yaml that it accepts. Previously, cloud-init emitted the key 'mtu6' for ipv6 MTU values. This is not correct and netplan will fail to parse these values. Netplan as of 0.98 supports both the info subcommand and the ipv6-mtu key. This branch modifies the netplan renderer to collect the netplan info output into a 'features' property which is a list of available feature flags which the renderer can use to modify its output. If the command is not available, no feature flags are set and cloud-init will render IPv6 MTU values just as MTU for the subnet.

Fix usages of yaml, and move yaml_dump to safeyaml.dumps.

2019-10-24T20:02:15+00:00

Here we replace uses of the pyyaml module directly with functions provided by cloudinit.safeyaml. Also, change/move cloudinit.util.yaml_dumps to cloudinit.safeyaml.dumps LP: #1849640

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