| Age | Commit message (Collapse) | Author |
|---|
|
This copyright change reflects previous changes that Juerg made for pylint and
pep8 cleanups.
From: Juerg Haefliger <juerg.haefliger@hp.com>
Date: Mon, 16 Jan 2012 10:45:12 +0100
|
|
From: Juerg Haefliger <juerg.haefliger@hp.com>
This pulls in the named patch for LP: #914739 with a few other changes.
|
|
From: Juerg Haefliger <juerg.haefliger@hp.com>
|
|
From: Juerg Haefliger <juerg.haefliger@hp.com>
|
|
From: Juerg Haefliger <juerg.haefliger@hp.com>
|
|
single line)
From: Juerg Haefliger <juerg.haefliger@hp.com>
|
|
From: Juerg Haefliger <juerg.haefliger@hp.com>
argument)
|
|
consume_userdata should really run always, rather than once per instance.
The documentation says that boothooks were on their own for per-instance
but since this routine was only being called once, they would only get
called once.
This modifies the behavior to be:
user_script: per_always
cloud_config : per_always
upstart_job : per_instance
cloud_boothook: per_always
In order to not break part handlers that are existing, and expect to only be
called once per instance, this adds a 'handler_version' item in a handler
that can indicate the version (currently 1 or 2). If it is 2, then the
hander will be passed the frequency (per-instance or per-always) that this
is being run. That way the handler can differenciate between them.
This also makes 'bootcmd' run every boot. That should be changable in
cloud-config though, so users who dont like the behavior can modify it.
LP: #819507
|
|
previously, cloud-init-cfg would call CloudConfig with no cloud
specified. Then, CloudConfig would get a new cloudinit instance
and specify no ds_deps (which means network and local).
If no cache was found, it would wait again for the Ec2 metadata
service (even if it wasn't supposed to).
Now, we get the cloud instance in the main program and attempt to
get the data source, but only from [], which will get only cached.
Then, if its not found, exit silently.
|
|
Adding the apt helper routines to CloudConfig.
Then, make use of the following from cc_puppet and cc_apt_update_upgrade
update_package_sources():
install_packages(pkglist):
I'm not really terribly happy with this location for them. Their presence
here is really only because of apt-update's use of
'run-once-per-instance'.
|
|
This method aloows the caller to run easily run something
"once per instance". Its location in CloudConfig rather than
'util' is really only because it needs access to cloudinit.get_ipath_cur
to get the 'data' path.
|
|
|
|
This will allow for a DataSource to provide its own config
that will then be utilized as part of CloudConfig.
[to be used in OVF]
|
|
|
|
This moves what was done as cloud-run-user-script.conf to 'cloud-final'
and makes that re-use the cloud-init-cfg code, but simply with a different
set of default configs.
Also, adds keys_to_console and final_message cloud-config modules
LP: #653271
|
|
|
|
add 'hostname' cloud-config option for setting hostname
make rsyslog and resizefs run at cloud-init time
|
|
|
|
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.
|
|
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.
|
|
to be debug (with traceback). The exception is still raised, but
no reason for the whole traceback to be on error
|
|
|
|
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)
|
|
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
|
