| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Take care of FreeBSD nic devicenames since they differ depending
on the platform involved. Xen/KVM use different drivers, which
results in different device names.
|
|
|
|
|
|
on the platform involved. Xen/KVM (Azure?) use different drivers, which
results in different device names.
|
|
|
|
User can now configure setting of a swap file.
Only supports un-encrypted swap for now.
swap:
filename: /swap.img
size: "auto" or size in bytes
maxsize: size in bytes
Also adds 2 util:
read_meminfo: return how much memory on system.
human2bytes: convert human numbers (8G) to bytes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add support for freebsd reading config drive. Primary work is
related to re-factoring mount_cb to not be so linux specific.
Other changes:
* declare PATH in freebsd initscripts
* list dependency on e2fsprogs (for blkid)
* enable ConfigDrive in freebsd config
* hosts.freebsd.tmpl added
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
add kwargs to fork_cb, and utilize that to call log_time and pass through
the provided args to resize_cmd.
LP: #1338614
|
|
|
|
|
|
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.
|
|
|
|
silently wait 5 seconds for networking to come up.
We started seeing the message more now, as we are now blocking
the networking from coming up until cloud-init-local is done.
Previously that would have happened in parallel, and we were less likely
to see that message.
|
|
This makes it so networking wont start to come up until after
cloud-init-local has had a chance to search local datasources
and write /etc/network/interfaces.
The changes most likely need to still be done for systemd.
LP: #1368861
|
|
not sure why this was here.
the intent must of have been to allow for a local datasource
to continue booting and not annoyingly block waiting for network information
(if ithere was no network information).
However, that seems wrong.
If the datasource wipes /etc/network/interfaces and there are no network
interfaces then we're probably breaking that use case here. However we're
fixing the other more common case.
|
|
|
|
Not all vendor data is destined for cloud-init. This sanely reads
the vendor data as a dict, array or a string.
|
|
|
|
This makes it so networking wont start to come up until after
cloud-init-local has had a chance to search local datasources
and set /etc/network/interfaces.
The changes most likely need to still be done for systemd.
LP: #1368861
|
|
|
|
With the writing of cloud-init status, cloud-init-local needs to
have /run mounted. The issue we were seeing was a race where:
cloud-init-local creates /run/cloud-init
/run is mounted
cloud-init-local tries to link a file into /run/cloud-init
that directory was no longer visisable as /run was mounted over
the top.
LP: #1353008
|
|
|
|
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.
|
|
This makes the DataSourceConfigDrive support vendor-data in the same
way the metadata service reader does. There are still some things to
fix here, but now we're similar between these two.
Also drops the ability to specify a version (as in YYYY-MM-DD) that you want to
look for. Nothing was using this, but it may be useful to add back in
in the future and expose as a datasource config option.
|
