Age | Commit message (Collapse) | Author |
|
This adds documentation intended for a developer on how to add
a new datasource to cloud-init.
|
|
The change to datasources.rst here is obvious typo fix.
The change to azure is to reduce the two 'Customization' sections
to a single and clean up some other duplicate text.
|
|
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
|
|
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 adds a Oracle specific datasource that functions with OCI.
It is a simplified version of the OpenStack metadata server
with support for vendor-data.
It does not support the OCI-C (classic) platform.
Also here is a move of BrokenMetadata to common 'sources'
as this was the third occurrence of that class.
|
|
Also document instance-data.json on the top-level datasource topic page.
|
|
Just add some documentation to readthedocs for AliYun.
|
|
Add some minimal documentation for GCE datasource.
|
|
|
|
The biggest things here are:
* move doc/sources/*/README.rst to doc/rtd/topics/datasources
This gives each datasource a page in the rtd docs, which make
it easier to read.
* consistently use the same header style throughout.
As suggested at
http://thomas-cokelaer.info/tutorials/sphinx/rest_syntax.html
use:
# with overline, for parts
* with overline, for chapters
=, for sections
-, for subsections
^, for subsubsections
“, for paragraphs
Also, move and re-format vendor-data documentation to rtd.
|
|
This adds lots of config module documentation in a standard format.
It will greatly improve the content at readthedocs.
Additionally:
* Add a 'doc' env to tox.ini
* Changed default highlight language for sphinx conf from python to yaml
most examples in documentation are yaml configs
* Updated datasource examples to highlight sh code properly
|
|
|
|
|
|
|
|
the Requires would get that string rendered into the package's
Depends/Requires (rather than BuildDepends/BuildRequires).
We should have BuildDepends/BuildRequires too, but since
trunk's package builds do not run 'make test', this isn't a big deal.
This also adds 'test-requires' for httpretty.
|
|
|
|
Add a base set for ec2 and datasource none.
|
|
Start moving the current README for
datasources to a RST format and include
those files in the rtd site.
LP: #1113650
|