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

Single JSON schema validation in early boot (#1175)

2022-01-18T17:05:29+00:00

Package a single JSON schema file for user-data validation at cloudinit/config/cloud-init-schema.json. Perform validate_cloudconfig_schema call to just after the user-data is consumed. This will allow single validation of all user-data against the full schema instead of repetitive validatation calls against each cloud-config module (cloudinit.config.cc_*) sub-schemas. This branch defines the simple apt_pipelining schema and migrates existing cc_apk_configure into cloud-init-schema.json. The expectation will be additional branches to migrate from legacy "schema" attributes inside each cloud-config module toward unique cc_ definitions in the global shema file under "$defs" of cloud-init-schema-X.Y..json. Before legacy sub-schema definitions are migrated the following funcs grew support to read sub-schemas from both static cloud-init-schema.json and the individual cloud-config module "schema" attributes: - get_schema: source base schema file from cloud-init-schema.json and supplement with all legacy cloud-config module "schema" defs - get_meta_doc: optional schema param so cloud-config modules no longer provide the own local sub-schemas - _get_property_doc: render only documentation of sub-schema based on meta['id'] provided - validate_cloudconfig_schema: allow optional schema param Additionally, fix two minor bugs in _schemapath_for_cloudconfig: - `cloud-init devel schema --annotate` which results in a Traceback if two keys at the same indent level have invalid types. - exit early on empty cloud-config to avoid a Traceback on the CLI

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.

Allow disabling of network activation (SC-307) (#1048)

2021-10-07T16:27:36+00:00

In #919 (81299de), we refactored some of the code used to bring up networks across distros. Previously, the call to bring up network interfaces during 'init' stage unintentionally resulted in a no-op such that network interfaces were NEVER brought up by cloud-init, even if new network interfaces were found after crawling the metadata. The code was altered to bring up these discovered network interfaces. On ubuntu, this results in a 'netplan apply' call during 'init' stage for any ubuntu-based distro on a datasource that has a NETWORK dependency. On GCE, this additional 'netplan apply' conflicts with the google-guest-agent service, resulting in an instance that can no be connected to. This commit adds a 'disable_network_activation' option that can be enabled in /etc/cloud.cfg to disable the activation of network interfaces in 'init' stage. LP: #1938299

Update pylint to v2.9.3 and fix the new issues it spots (#946)

2021-07-20T14:58:21+00:00

In CI run against pylint 2.9.3 and fix occurrences of: - W0237 (arguments-renamed) - W0402 (deprecated-module) The W0402 deprecated-module was about module `imp`: cloudinit/patcher.py:9: [W0402(deprecated-module), ] Uses of a deprecated module 'imp' The imp module is deprecated and replaced by importlib, which according to the documentation has no replacement for acquire_lock() and release_lock(), which are the only reason why `imp` is imported. Nothing about the code using this lock that actually requires it. Let's remove the locking code and the import altogether. Dropping the locking makes patcher.patch() an empty wrapper around _patch_logging(). Rename _patch_logging() to patch_logging() and call it directly instead. Drop patch().

- Detect a Python version change and clear the cache (#857)

2021-07-01T16:35:40+00:00

summary: Clear cache when a Python version change is detected When a distribution gets updated it is possible that the Python version changes. Python makes no guarantee that pickle is consistent across versions as such we need to purge the cache and start over. Co-authored-by: James Falcon

Drop unnecessary shebang from cmd/main.py (#722)

2020-12-10T18:10:43+00:00

Fedora build system's rpmlint is complaining that there is a file with a shebang but no executable flag set. No need to have shebang on this file, so drop it. Signed-off-by: Eduardo Otubo Co-authored-by: Scott Moser

cmd:main.py: Fix missing 'modules-init' key in modes dict

2019-04-09T14:54:23+00:00

Cloud-init's main.py will fail when presented with a new stage name 'modules-init' if upgrading an older cloud-init. Fix this by initializing unknown stage names before accessing. LP: #1815109

dhclient-hook: cleanups, tests and fix a bug on 'down' event.

2018-12-03T22:07:59+00:00

I noticed a bug in dhclient_hook on the 'down' event, using 'is' operator rather than '==' (if self.net_action is 'down'). This refactors/simplifies the code a bit for easier testing and adds tests. The reason for the rename of 'action' to 'event' is to just be internally consistent. The word and Namespace 'action' is used by cloud-init main, so it was not really usable here. Also adds a main which can easily be debugged with: CI_DHCP_HOOK_DATA_D=./my.d python -m cloudinit.dhclient_hook up eth0

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