| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix cloud-init schema --system being unable to find merged
userdata stored at /var/lib/cloud/instance/cloud_config.txt.
Init.paths.get_ipath only has visibility to merged cloud config in
/var/lib/cloud/<instance_id>/cloud-config.txt after fetching the
existing cached datasource which provides instance-id from metadata
in order to determine the unique instance-id which represents the
path to the cloud-config.txt.
To support reuse of read_cfg_paths helper function, add an optional
parameter fetch_existing_datasource which indicates whether reading
the existing datasource is necessary for this helper function.
cloud-init schema --system calls read_cfg_paths providing
fetch_existing_datasource="trust" prior to calls to
paths.get_ipath().
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For non-root users, emit warnings and redact on any
/etc/cloud/cloud.cfg.d files which raise permissions errors.
Add tests covering this behavior for query, status and render
cmds.
Migrate `test_render.py` and `test_status.py` to Pytest.
LP: #1953430
SC-658
|
| |
|
|
| |
- move datasource helpers to dedicated directory
- drop unnecessary executable bit on shebangless python files
|
| |
|
|
|
| |
Applied Black and isort, fixed any linting issues, updated tox.ini
and CI.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
'<v#>' 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
|
|
|
This branch does a few things:
- Add 'schema' subcommand to cloud-init CLI for validating
cloud-config files against strict module jsonschema definitions
- Add --annotate parameter to 'cloud-init schema' to annotate
existing cloud-config file content with validation errors
- Add jsonschema definition to cc_runcmd
- Add unit test coverage for cc_runcmd
- Update CLI capabilities documentation
This branch only imports development (and analyze) subparsers when the
specific subcommand is provided on the CLI to avoid adding costly unused
file imports during cloud-init system boot.
The schema command allows a person to quickly validate a cloud-config text
file against cloud-init's known module schemas to avoid costly roundtrips
deploying instances in their cloud of choice. As of this branch, only
cc_ntp and cc_runcmd cloud-config modules define schemas. Schema
validation will ignore all undefined config keys until all modules define
a strict schema.
To perform validation of runcmd and ntp sections of a cloud-config file:
$ cat > cloud.cfg <<EOF
runcmd: bogus
EOF
$ python -m cloudinit.cmd.main schema --config-file cloud.cfg
$ python -m cloudinit.cmd.main schema --config-file cloud.cfg \
--annotate
Once jsonschema is defined for all ~55 cc modules, we will move this
schema subcommand up as a proper subcommand of the cloud-init CLI.
|
