| Age | Commit message (Collapse) | Author |
|---|
|
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()
|
|
reading /proc/uptime is going to be slower, and no reason to do it on most
things. Better to only do it when you suspect maybe a need for it.
|
|
The reason for this is that more and more things I was wanting to be able to
see how long they took. This puts that time logic into a single place. It
also supports (by default) reading from /proc/uptime as the timing mechanism.
While that is almost certainly slower than time.time(), it does give
millisecond granularity and is not affected by 'ntpdate' having
run in between the two events.
|
|
This most commonly occurs if a user-data script does '/sbin/poweroff'
where syslog was being used. Once poweroff is invoked, syslog gets killed
and logging would start to show stack traces.
This generally tries to continue working instead, but log to stderr.
|
|
is to patch the functionality before it gets reimported.
|
|
handle those signals more gracefully and
with better messaging than what comes builtin.
|
|
a config module and make it more generic in that it can take in a list
of event names to emit as arguments. Add a yaml example to replace the functionality
removed from the main binary.
|
|
The merge of 0.7.0 dropped the cloud-config initctl emission.
I've added it back here, but done so in a way that doesn't force
non-ubuntu (or non-upstart) distros to provide this config setting
to disable it.
LP: #1028674
|
|
when running in local mode vs non-local mode, which
is useful when tracking what is happening in the
console and in the logs that are written out later.
|
|
If the user has input logging information in user-data cloud-config
we want to set up the logging to accept that after the data source
has been read.
|
|
in the 'cloud-init init' stages, we want the welcome message to get to the
correct output as specified by the system's configuration. Ie, if the
local /etc/cloud.config.d had 'output' or 'log_cfg' settings we want those
to be able to affect the welcome message also.
In normal operation, nothing else will go to stdout or stderr before this,
and likely/hopefully nothing terribly important to the logs.
|
|
Instead of a warning, only debug this message. Warnings get to
console and look scary to users.
|
|
At this point there is a mixture of "double hash" cheetah comments and '#*'
cheetah comments.
|
|
module
2. Fix the usage of multi_log to log to only one of the places (for now)
3. Update comment about multi-log and why write_file isn't used in this case
|
|
useful in certain cases
|
|
that occur to stderr.
|
|
datasource is found.
|
|
|
|
very obvious.
|
|
comments into the files)
2. Rename consume() to consume_userdata() as it helps in figuring out what this does.
3. Fixup the tests due to #2
|
|
handles this.
|
|
2. Use that list in the main binary & adjust related comparisions
|
|
|
|
2. Adjust comment on sources list from depends
3. For the /etc/timezone 'writing', add a header that says created by cloud-init
|
|
2. For single modules, if it doesn't run, print a warning and exit with a return code of 1
|
|
|
|
|
|
2. Reflect the move back to config 'modules' in the other cli options
3. Have the single mode not need to lookup the module but use the general import path
|
|
|
|
|
|
|
|
|
|
|
|
|
|
useful exit code
2. Add in the single transform running stub, which seems to be a feature of the previous cloud-init-cfg, making it its own action now
3. Adding in the 'config' and 'final' actions, which now both go through the same entrypoint function to setup the initial object
and then fire off the needed transforms.
4. Cleanup of the argparsing code to handle the above cases.
|
|
2. Add a mode option in to the 'config' subparser that allows the user to affect the transform selection phase
3. Some tiny pylint warnings.
|
|
|
|
|
|
|
|
2. Add the ability to take in multiple extra config files (mainly for debugging)
3. Move 'simple' welcome message to this file
4. Only setup initial basic logging if '-d' option is provided.
|
|
Main features:
1. Use of argparse + subcommands to handle 'action' specific actions
a. Actions being 'query', 'init', 'final', 'config'
!WIP!
|
|
|
