| Age | Commit message (Collapse) | Author |
|---|
|
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 has been a recurring ask and we had initially just made the change to
the cloud-init 2.0 codebase. As the current thinking is we'll just
continue to enhance the current codebase, its desirable to relicense to
match what we'd intended as part of the 2.0 plan here.
- put a brief description of license in LICENSE file
- put full license versions in LICENSE-GPLv3 and LICENSE-Apache2.0
- simplify the per-file header to reference LICENSE
- tox: ignore H102 (Apache License Header check)
Add license header to files that ship.
Reformat headers, make sure everything has vi: at end of file.
Non-shipping files do not need the copyright header,
but at the moment tests/ have it.
|
|
to be behind trunk.
`tox -e py27` passes full test suite. Now to work on replacing mocker.
|
|
This just removes comments '# pylint:' things and other code
remnents of pylint.
|
|
|
|
|
|
|
|
|
|
After user data handling splits apart all the different
content types into there various mime messages it is
nice to be able to have each message specify how it should
be merged (mainly for cloud-config or cloud-archive) into
the single cloud config that is eventually used. This
starts to add a plugable merging framework and the
needed components to activate said headers and merging.
|
|
empty might be valid
|
|
This allows for others to use datasource functions if they desire to instead of being restricted.
+1 for future use ;)
|
|
just util functions and base classes are defined there.
|
|
|
|
|
