| Age | Commit message (Collapse) | Author |
|---|
|
This drops the hard requirement on Cheetah.
Jinja is a python 2.4->3.x compatible templating engine, allow its
optional usage (until we can depreciate cheetah) by allowing for
specifying a template file header that can define which template engine to
use.
If the template file header does not specify a renderer, then assume
that that is cheetah. If cheetah is not available, then use a limited
builtin renderer on a best effort basis, and log the warning.
LP: #1219223
|
|
|
|
|
|
|
|
|
|
|
|
A few of the current tests have been continually failing
in python 2.6 based systems, due to lack of unit test
functions that are now added to ensure we can run the
unit tests (and not have to ignore those failures) on
python 2.6
|
|
|
|
|
|
Removes some of the log messages that are not really meaningful.
|
|
|
|
|
|
|
|
Adjust the TODO file to be in rst format (which is nicer
to look at) and remove some of the TODO items that are no
longer relevant.
|
|
LP: #1327065
|
|
LP: #1316597
|
|
On systems with a ttyS1 and nothing attached, the read attempts
that the cloud sigma datasource would do would block.
Also, Add timeouts for reading/writting from/to the serial console
LP: #1316475
|
|
* do not run dmidecode on arm.
* line length
* comment that 60 second time out is expected
|
|
LP: #1303986
|
|
|
|
|
|
|
|
|
|
|
|
This change adds the possibility to have base64 encoded userdata in
OpenNebula source.
OpenNebula uses a text file with shell variables for storing the
configuration variables (including user provided data). Some user data may
not be renderable into this format, so using base64 encoding alleviates
the problem.
The change here allows the user to provide a second variable
USERDATA_ENCODING (or USER_DATA_ENCODING) and set that value to 'base64'
to indicate that USERDATA is base64 encoded.
|
|
Instead of just trying to see if userdata decodes as the indication that
it should be encoded, the user must explicitly set this.
The "just try it" will fail in the case where the user had other use
of user-data and wanted a blob of data to go through unrecognized by
cloud-init.
In cases where there can be mistake in automatic behavior,
and some users may be relaying on old behavior, its best to just require
explicit use.
|
|
|
|
This was broken in the VendorData add.
LP: #1295223
|
|
|
|
On azure, the ephemeral disk may be destroyed and replaced with a fresh
ephemeral disk on any reboot or stop and start cycle.
This makes the datasource able to detect that by presence of an unformatted
and specifically labeled NTFS filesystem with no files on it.
LP: #1292648
|
|
|
|
|
|
per instance. Under a variety of circumstances, the ephemeral device may
be presented as a default device. This patch detects when that situation
happens and triggers CC modules disk-setup and mounts to run again.
Details of changes for cloudinit/sources/DataSourceAzure.py:
- auto-detect the location of ephemeral0
- check each boot if ephemeral0 is new
- done via NTFS w/ label of "Temporary Storage" w/ no files on it
- if device is mounted, datasource will unmount it
- if is new, change mounts and disk-setup to always for that boot only
|
|
documentation of final_message in
doc/examples/cloud-config-final-message.txt
showed '$UPTIME' and '$TIMESTAMP' would be available, but
only the lower case versions of these strings were available.
This change just makes all lower case and upper case keys
available here to avoid breaking anyone who used the
functional-but-not-correctly-documented lower case names.
LP: #1286164
|
|
|
|
|
|
call the command without capturing output, and provide RANDOM_SEED_FILE
to the environment that it is run in.
|
|
|
|
This adds the ability to read a 'base64_fields' entry in the metadata,
and if cloud-init-userdata is listed in that, then content will be
base64 decoded first.
|
|
This populates and maintains status.json and result.json with
json formated data about cloud-init's errors and datasource.
It is intended to be consumed by other programs that want to
wait until cloud-init is done, or know its success.
LP: #1284439
|
|
|
|
This extends 'random_seed' top level entry to include a 'command'
entry, that has the opportunity to then seed the random number generator.
Example config:
#cloud-config
random_seed:
command: ['dd', 'if=/dev/zero', 'of=/dev/random', 'bs=1M', 'count=10']
LP: #1286316
|
|
by default we call 'pollinate -q' which is nice and quiet.
if the user wants to be noisy, let them.
|
|
there was a bug that prevented seeding of /dev/urandom from metadata provided
by the datasource unless the user provided random_seed config.
This should, instead, be the default behavior.
|
|
Mako is a python 2.6->3.x compatible
templating engine, allow its optional
usage (until we can depricate cheetah)
by allowing for specifying a template
file header that can define which template
engine to use.
For now support cheetah (the default) and
if specified support mako as well.
|
|
|
|
if you have UNCOMMITTED=1 in environment then the tree will
contain uncommitted changes.
|
|
Similar test-hack as the SmartOS one.
Here we just pretend that we're running on x86_64 so as to avoid
re-writing the tests to expect otherwise on arm.
|
|
|
|
As with SmartOS change earlier, running dmidecode on arm will crash kvm.
So instead of doing that, just return UNKNOWN which will cause this
data source to not activate.
LP: #1285686
|
