| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Previously, all you would get was a warning to the console on config
module failure. This changes to get a stack trace of the failure to the
console, which is much easier for debugging.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ec2-run-instances
--block-device-mapping /dev/sdd=:1
--block-device-mapping /dev/sde=snap-4cda7b24
--block-device-mapping sdf=snap-d4d90bbc
resulted in:
'block-device-mapping': {'ami': '/dev/sda1',
'ebs1': '/dev/sdd',
'ebs2': '/dev/sde',
'ebs3': 'sdf',
'ephemeral0': '/dev/sda2',
'root': '/dev/sda1',
'swap': 'sda3'}
|
|
|
|
It just seems like for cloud instances, getting /etc/fstab written
incorrectly with the result of non-booting system is worth avoiding.
|
|
What caused this was having an open ended list on what "names" might be
found in the metadata service. That list is now trimmed down to the
the following values:
ephemeral*
root
ami
swap
The above list was found from crawled medata data services in the latest
maverick tests I did. The following is the complete list of entries that
were there:
'ami': '/dev/sda1',
'ami': 'sda1',
'ephemeral0': '/dev/sda2'
'ephemeral0': '/dev/sdb'
'ephemeral0': 'sda2'
'ephemeral0': 'sdb'
'ephemeral1': 'sdc'
'ephemeral2': 'sdd'
'ephemeral3': 'sde'
'root': '/dev/sda1'
'root': '/dev/sda1'
'swap': 'sda3'
Also, this limits which devices will have "/dev/" prepended to them to
sda, sda1, xvda, xvda1, hda1, hda, vda.
LP: #603329
|
|
|
|
|
|
On EBS instances, a shutdown and later start would end up with a
different IP address.
In the case where the user has not modified /etc/hostname from its
original value (seeded by metadata's 'local-hostname'), then cloud-init
will again set the hostname and update /etc/hostname.
In the case where the user *has* modified /etc/hostname, it will remain
user managed.
Additionally, if /etc/cloud/cloud.cfg contains 'preserve_hostname' value
set to a True value, then /etc/hostname will not ever be touched.
LP: #596993
|
|
The starts-with determination of mime type was overriding an explicit
setting in the mime-type. This was evident when the mime type specified
boothook, but the content began with '#!'. In that case, the content
would run as a user script rather than boothook.
LP: #600799
|
|
|
|
The goal was to remove '#cloud-boothook' from a part if the part
started that way. This was to allow user data of
#cloud-boothook
#!/usr/bin/perl
...
to be handled correctly. That had 2 bugs
1.) the prefix string was wrong
2.) was checking for '\r' in the wrong location
|
|
|
|
If user gives bad cloud-config syntax, its not very useful to die, as
that is most likely to leave the system unreachable. This instead
logs the error and continues as if it no cloud-config was given.
|
|
nobootwait is likely important if the user is attempting to set up ebs
volume mount points via this mechanism. See 'man fstab' for more
inforation on this option
|
|
|
|
|
|
|
|
|
|
|
|
LP: #582667
|
|
|
|
The previous syntax was either
cloud-init-cfg all
or
cloud-init-cfg <name> args
Ie, you could not specify the frequency if you gave a name. Now, you can.
Something like:
sudo cloud-init-cfg ssh always
|
|
to be debug (with traceback). The exception is still raised, but
no reason for the whole traceback to be on error
|
|
This is useful for getting a config option that is either string or a
list as a list
|
|
568139 was fixed because the test for "always" was using "is"
instead of "=="
LP: #568139
|
|
|
|
Previously, most of the config semaphores were prefixed with 'config-'.
Ie, a sem/ list would look like:
apt-update-upgrade.i-7c908817
config-misc.i-7c908817
config-mounts.i-7c908817
config-puppet.i-7c908817
config-ssh.i-7c908817
consume_userdata.i-7c908817
disable-ec2-metadata.always
set_defaults.i-7c908817
set_hostname.i-7c908817
With the last release (0.5.11), those config- would have been removed.
I'll handle this correctly yuckyness in the ubuntu package upgrade
(avoiding re-running scripts that were already ran)
|
|
|
|
|
|
|
|
passing the instance-id of this instance to a boothook will give it
the unique id that is needed to implement run-once-per-instance.
|
|
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.
|
|
|
|
|
|
The list of cloud-config modules is now kept in cloud config itself.
There is a builtin list in cloudinit, which is overrideable by
/etc/cloud/cloud.cfg or user data cloud-config.
This should make the modules more easily added or removed (as no code
needs to be edited now)
Basic summary of changes:
- move CloudConfig.py -> cloudinit/CloudConfig/__init__.py
- split cloud-config modules into their own files named
cloudinit/CloudConfig/cc_<name>.py
- remove all the upstart/cloud-config-* scripts, replacing them with
upstart/cloud-config.conf
|
|
remove the section, these should be covered in 'builtin'. The content was
correct, just not needed.
Added an example to doc/examples/cloud-config.txt on how the user can
configure this from either cloud-config user data or from
/etc/cloud/cloud.cfg
|
|
|
|
use get_base_cfg from CloudInit:read_cfg
|
|
|
|
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
|
|
|
