| Age | Commit message (Collapse) | Author |
|---|
|
this simplifies consume_vendordata a bit, changes consume_vendordata to
be by default "PER_INSTANCE" (like userdata).
The other thing we do here is move the exlusion to be handled when walking the
data. The benefit of doing it then is that we can exclude part-handlers.
Without the ability to exlude part handlers, exclusion is basically useless
(since part-handlers could accomplish anything they wanted).
|
|
remove apply_filter from get_vendordata. I can't think of a good
reason to filter vendor-data per instance-id.
remove has_vendordata and consume_vendordata.
has vendordata is always "true", whether or not there is something
to operate is determined by:
if ds.vendordata_raw()
consume_vendordata is based on config entirely.
|
|
|
|
this makes runparts take exe_prefix and do string to list conversion
inside. that means we don't have to do it in cc_scripts_vendor.
Also, get_nested_option_as_list was essentially get_cfg_by_path anyway.
|
|
I don't see a real need for these. The intent of the 'per-boot' or
'per-instance' or 'per-once' config modules is to handle running
scripts that were already inserted into the instance.
If the vendor is doing that, then there is value in vendor-data.
Ie, they'd already modified the image, they might as well have just
put the stuff in that they wanted.
|
|
|
|
|
|
We were passing a unicode string to 'runcmd' in the path to the .crt file.
That is because the keyname was coming from ovf file as unicode.
Ie:
u'/var/lib/waagent/6BE7A7C3C8A8F4B123CCA5D0C2F1BE4CA7B63ED7.crt'
Then, logging was extending not appending errors.
|
|
|
|
|
|
vendordata.
Vendordata is a datasource provided userdata-like blob that is parsed
similiarly to userdata, execept at the user's pleasure.
cloudinit/config/cc_scripts_vendor.py: added vendor script cloud config
cloudinit/config/cc_vendor_scripts_per_boot.py: added vendor per boot
cloud config
cloudinit/config/cc_vendor_scripts_per_instance.py: added vendor per
instance vendor cloud config
cloudinit/config/cc_vendor_scripts_per_once.py: added per once vendor
cloud config script
doc/examples/cloud-config-vendor-data.txt: documentation of vendor-data
examples
doc/vendordata.txt: documentation of vendordata for vendors
(RENAMED) tests/unittests/test_userdata.py => tests/unittests/test_userdata.py
TO: tests/unittests/test_userdata.py => tests/unittests/test_data.py:
userdata test cases are not expanded to confirm superiority over vendor
data.
bin/cloud-init: change instances of 'consume_userdata' to 'consume_data'
cloudinit/handlers/cloud_config.py: Added vendor script handling to default
cloud-config modules
cloudinit/handlers/shell_script.py: Added ability to change the path key to
support vendor provided 'vendor-scripts'. Defaults to 'script'.
cloudinit/helpers.py:
- Changed ConfigMerger to include handling of vendordata.
- Changed helpers to include paths for vendordata.
cloudinit/sources/__init__.py: Added functions for helping vendordata
- get_vendordata_raw(): returns vendordata unprocessed
- get_vendordata(): returns vendordata through userdata processor
- has_vendordata(): indicator if vendordata is present
- consume_vendordata(): datasource directive for indicating explict
user approval of vendordata consumption. Defaults to 'false'
cloudinit/stages.py: Re-jiggered for handling of vendordata
- _initial_subdirs(): added vendor script definition
- update(): added self._store_vendordata()
- [ADDED] _store_vendordata(): store vendordata
- _get_default_handlers(): modified to allow for filtering
which handlers will run against vendordata
- [ADDED] _do_handlers(): moved logic from consume_userdata
to _do_handlers(). This allows _consume_vendordata() and
_consume_userdata() to use the same code path.
- [RENAMED] consume_userdata() to _consume_userdata()
- [ADDED] _consume_vendordata() for handling vendordata
- run after userdata to get user cloud-config
- uses ConfigMerger to get the configuration from the
instance perspective about whether or not to use
vendordata
- [ADDED] consume_data() to call _consume_{user,vendor}data
cloudinit/util.py:
- [ADDED] get_nested_option_as_list() used by cc_vendor* for
getting a nested value from a dict and returned as a list
- runparts(): added 'exe_prefix' for running exe with a prefix,
used by cc_vendor*
config/cloud.cfg: Added vendor script execution as default
tests/unittests/test_runs/test_merge_run.py: changed consume_userdata() to
consume_data()
tests/unittests/test_runs/test_simple_run.py: changed consume_userdata() to
consume_data()
|
|
Before passing a path into selinux.matchpathcon, it needs to be casted
to a string, since the path could be unicode and selinux.matchpathcon
does not support unicode.
LP: #1260072
|
|
This allows a general config option to prefix apt-get commands via
'apt_get_wrapper'. By default, the command is set to 'eatmydata', and the
mode set to 'auto'. That means if eatmydata is available (via which), it
will use it.
The 'command' can be either a array or a string.
LP: #1236531
|
|
Before passing a path into selinux.matchpathcon, it needs to be casted
to a string, since the path could be unicode and selinux.matchpathcon
does not support unicode.
Closes-Bug: #1260072
LP: #1260072
|
|
This adds a debug module for printing debug output. It does not enable it
by default (by putting it in in cloud_config_modules or elsewhere).
Thats fine, as it is still quite useful for the user to run:
sudo cloud-init single --frequency=always --name=debug ci-debug.txt
|
|
Let the command line (or module args) that set outfile explicitly
override a config'd value of 'verbose'.
Ie, if /etc/cloud/cloud.cfg.d/my.cfg had:
debug:
verbose: False
but the user ran:
cloud-init single --frequency=always --name=debug output.txt
Then they probably wanted to have the debug in output.txt even
though verbose was configured to False.
|
|
This fixes warnings raised by:
./tools/run-pep8 cloudinit/config/cc_debug.py
./tools/run-pylint cloudinit/config/cc_debug.py
|
|
Since the import failure can be an expected failure do not log that
failure at a WARNING level, but to start log it at a DEBUG level. This
will help in figuring out why imports fail (if they ever do) for developer
and cloud-init users. Previously it is hard to know if a module fails
importing for a valid reason (not existent) or an invalid reason (the
module exists but the module has a dependency which is not satisfied).
|
|
|
|
|
|
|
|
argument for output file
|
|
some information about the instance being created.
The module can be included at any stage of the process
- init/config/final
LP: #1258619
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
LP: #1244355
|
|
|
|
LP: #1232175
|
|
In certain cases import failure is
expected and in certain cases it is
not expected, in either case it is
useful to at least log the failure.
|
|
this adds 'timeout' to the documentation for power_state_change, and
supports delay being an integer or a string. This is so that yaml
can contain:
delay: 30
rather than
delay: "+30"
or
dealy: "30"
|
|
The expected behavior was that 'ephemeral0' in a mount device entry
and ephemeral0 mapped to /dev/xvdb that /dev/xvdb1 or /dev/xvdb would
be substituted.
Explicitly setting 'ephemeral0.0' would mean only xvdb in this case.
LP: #1236594
|
|
|
|
|
|
LP: #1236445
|
|
|
|
The use of availability-zone or availability_zone is provided by the base
classes's behavior.
|
|
|
|
|
|
|
|
|
|
|
|
formating support.
|
|
|
|
|
|
|
