| Age | Commit message (Collapse) | Author |
|---|
|
Previous logging was getting 'None' set in the DataSource collections.
Thus, 'log.debug' would throw error. I think it is proper to pull in
the base cloudinit's log.
|
|
After adding the 'log' element to the DataSource class, pickling would
fail with
TypeError: can't pickle file objects
Instead of having the object with a log reference, use one from
'DataSource.log' and have that set by cloudinit
|
|
The DataSources that are loaded are now controlled entirely via
configuration file of 'datasource_list', like:
datasource_list: [ "NoCloud", "OVF", "Ec2" ]
Each item in that list is a "DataSourceCollection". for each item
in the list, cloudinit will attempt to load:
cloudinit.DataSource<item>
and, failing that,
DataSource<item>
The module is required to have a method named 'get_datasource_list'
in it that takes a single list of "dependencies" and returns
a list of python classes inside the collection that can run needing
only those dependencies.
The dependencies are defines in DataSource.py. Currently:
DEP_FILESYSTEM = "FILESYSTEM"
DEP_NETWORK = "NETWORK"
When 'get_datasource_list' is called for the DataSourceOVF module with
[DEP_FILESYSTEM], then DataSourceOVF returns a single item list with a
reference to the 'DataSourceOVF' class.
When 'get_datasource_list' is called for the DataSourceOVF module with
[DEP_FILESYSTEM, DEP_NETWORK], it will return a single item list
with a reference to 'DataSourceOVFNet'.
cloudinit will then instanciate the class and call its 'get_data' method.
if the get_data method returns 'True', then it selects this class as the
selected Datasource.
|
|
Everywhere that there occurred:
except Exception, e:
changed to
except Exception as e:
|
|
|
|
- cloud_config and scripts now live in instance directory
- cachedir is now more correctly named 'seeddir'
|
|
Previously the 'get_locale()' method of DataSourceEc2 would select
a default locale based on the availability zone that the instance was
running on.
I generally don't like that as
a.) there are loads of other locales than en_US and en_GB (that were being
used)
b.) either one is almost certainly not really the users preferred locale.
Just because I launch an instance in eu-west-1 doesn't mean I perfer en_GB.
|
|
VPC instances cannot reach other hosts in EC2 (such as the archives).
In this case, use the default mirror instead.
LP: #615545
|
|
|
|
The logic behind returning a device even if it is not present is that
it *could* be present later, or after a stop and restart. Additionally
this gives the caller more information to differenciate itself between
"device did not exist" and "device was not present in metadata service".
|
|
using read_optional_seed in DataSourceEc2 and DataSourceNoCloud.
change parse_cmdline_data to fill a dictionary that is supplied by
caller. It then returns strictly true or false based on whether
or not it was specified in cmdline
|
|
The new classes 'DataSourceNoCloud' and 'DataSourceNoCloudNet'
implement a way to get data from the filesystem, or (very minimal)
data from the kernel command line. This allows the user to seed data to
these sources.
There are now 2 "cloud-init" jobs, cloud-init-local that runs on
mounted MOUNTPOINT=/
and 'cloud-init' that runs on
start on (mounted MOUNTPOINT=/ and net-device-up IFACE=eth0 and
stopped cloud-init-local )
The idea is that cloud-init-local can actually function without network.
The last thing in this commit is "uncloud-init".
This tool can be invoked as 'init=/usr/lib/cloud-init/uncloud-init'
It will "uncloudify" things in the image, generally making it easier
to use for a simpler environment, and then it will exec /sbin/init.
|
|
device names presented in the metadata service may not be what the kernel
has named them. This can be for more than 1 reason. But some examples:
- device is virtio, metadata named 'sd'
- device is xvdX, metadata named sd
Those are the two situations that are covered here. More complex, but
not covered are possibly:
- metadata service named device 'sda1', but it should actually be 'vdb1'
LP: #611137
|
|
|
|
|
|
if user data is of type text/cloud-boothook, or begins with
#cloud-boothook, then assume it to be code to be executed.
Boothooks are a very simple format. Basically, its a one line header
('#cloud-config\n') and then executable payload.
The executable payload is written to a file, then that file is executed
at the time it is read. The file is left in
/var/lib/cloud/data/boothooks
There is no "first-time-only" protection. If running only once is
desired, the boothook must handle that itself.
|
|
This logging infrastructure in cloudinit:
- uses python logging
- allows user supplied config of logging.config.fileConfig format to be
supplied in /etc/cloud/cloud.cfg or in cloud_config by user data.
- by default, tries to use syslog, if that is not available, writes directly to
/var/log/cloud-init.log (syslog will not be available yet when cloud-init
runs)
- when using syslog, the doc/21-cloudinit.conf file provides a rsyslogd
file to be placed in /etc/rsyslog.d/ that will file [CLOUDINIT] messages
to /var/log/cloud-init.log
|
|
|
|
Also
- adds some debugging information when its waiting
- add 'uptime' printout on initial cloud-init invocation
|
|
|
|
|
