| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This was previously broken anyway. It doesn't seem like there
was an easy way to actually support it, so for now I'm removing
it entirely. growpart works well enough.
|
|
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.
|
|
|
|
|
|
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()
|
|
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
|
|
|
|
|
|
|
|
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
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
formating support.
|
|
|
|
|
|
makes it cloud agnostic.
|
|
|
|
I'm pretty sure the previous code wasn't seeking correctly
and probably writing near the end, but not to the end.
This is simpler and probably faster.
|
|
|
|
|
|
Modified cc_mounts to identify whether ephermalX is partitioned.
Changed datasources for Azure and SmartOS to use 'ephemeralX.Y' format.
Added disk remove functionally
|
|
cloud-initramfs-growroot is an initramfs module in cloud-initramfs-tools
that resizes the root partition before the root is pivoted over.
growroot was used in Ubuntu up to and including 12.10. The file
/etc/growroot-disabled on the root filesystem was the only way of
disabling the growing of the root partition.
In cloud-init 0.7.2 cloud-init began resizing the root partition
as growpart gained the ability to utilize 'ptupdate' in kernels > 3.8.
This was a big improvement as now the user could disable or enable
the growing of the root partition via user-data.
In order to let users disable growing of / very simplistically cloud-init
will now respect the presense of /etc/growroot-disabled unless config
specifically tells it to ignore that file.
LP: #1234331
|
|
|
|
|
|
Since for a string there is no difference, we're just
checking for this here.
|
|
|
|
|
|
|
|
this adds 2 functions
update_disk_setup_devices
update_fs_setup_devices
Which update the appropriate datatype, and translate the names.
Translating early means we don't have to deal with updating in the mkfs or
mkpart calls explicitly.
These are more easily unit tested as they just take a dictionary of the
expected type and a 'transformer' that should return a new name or None.
|
|
|
|
|
|
|
|
|
|
Some containers lack /dev/console, so when multi_log attempts to open
that device and write to it directly things can start going haywire.
Here we address this problem by sending console-bound output to stdout
and letting init take care of getting it to the console instead.
We already configure upstart with "console output", so we need only
change systemd to use "journal+console".
The one reason that 'console output' might not be sufficient is if
the user redirected output with 'output'. Ie:
output:
init: "> /var/log/my-cloud-init.log"
Would then mean all output would go there, and anything that
*needed* to go to the console (and was explicitly using multi_log for
that purpose) would not get there.
|
|
|
