| Age | Commit message (Collapse) | Author |
|---|
|
Standardize on using the chef_cfg key 'exec' which can be used
when installing to tell the caller to run the chef client or can
also be used if the client is already installed and its requested
to be ran.
To retain existing behavior 'exec' does not by default assume to
be true, unless explicitly provided or a gems mode install is
requested.
|
|
|
|
|
|
When the template provides a path, make sure that before the
template is written that the path that is now in the template
has the associated directory created (if not already created).
|
|
|
|
|
|
|
|
|
|
Instead of only running the client when installed from gems, allow it
to be ran from other install modes as well (if configured) and allow the
arguments that are passed to the client when ran to be altered (if so
desired).
|
|
- Use the generated_by() utility function to
give the ruby template a better header comment
- Set special parameters after selecting the basic
chef parameters.
|
|
- Make a helper function to tell if already installed.
- Have the install routine not run chef after installed
but have it instead return a result to tell the caller
to run the chef program once completed.
|
|
|
|
|
|
|
|
Add the following adjustments to the chef template and module
- Make it so that the chef directories can be provided (defaults
to the existing directories)
- Make the params much more configurable, and if a parameter is
provided in the chef configuration it will override existing template
parameters.
- Make the template skip lines if the values are None in the configuration
so that template lines can be removed if/when this is desirable.
- Allow the firstboot json path to be configurable (defaults to the
existing location).
- Adds a basic set of tests to ensure that good things are happening.
|
|
|
|
on the platform involved. Xen/KVM (Azure?) use different drivers, which
results in different device names.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
this supports a list of input, and cleans up that list
for the platform specific mount types. Basically,
mtype = None
means 'mount -t auto' or the equivalent for the platform.
and 'iso9660' means "iso type".
|
|
|
|
This allows the caller to supply their own leaf decoder, which will
then be in charge of translating the content of the url.
|
|
HVM instances on EC2 have grub on /dev/xvda.
The bug here resulted in a prompt on grub update.
LP: #1336855
|
|
|
|
|
|
util.log_time()'s return value was what was being sent to fork_cb. This means
the resize ran in parallel and the call to fork_cb threw a traceback (trying
to call Nonetype).
By permitting fork_cb to take kwargs, and using the correct method syntax,
this now forks and resizes in the background as appropriate.
|
|
|
|
|
|
For now, this vendor data handling is just added to openstack.
However, in an effort to allow sanely handling of multi-part vendor-data
that is namespaced, we add openstack.convert_vendordata_json .
That basically takes whatever was loaded from vendordata and takes
the 'cloud-init' key if it is a dict. This way the author can
namespace cloud-init, basically telling it to ignore everything else.
|
|
We were checking for presense of meta_data.json for each supported
metadata version. Instead just check that /openstack is there.
This reduces the time to check on EC2 or any other cloud.
|
|
instead of taking a version that they should look for,
the readers now just select the highest supported version.
definitely a use case later for having version= but nothing
is using it now.
|
|
|
|
|
|
|
|
using tuple for _versions was just not necessary.
fix reference to undefined os_versions.
|
|
If something is broken as in a built in config, or code
just broken, then logging warning during search for metadata
is ok.
|
|
make pyflakes now passes.
|
