| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This changes the way that we avoid cloud-init-nonet hanging in a container.
Previously, under LP: #800824 we tried 'start networking', but that caused
issues described in LP: #1031065.
Here, we emit the net-device-added for any devices that have not yet been
seen.
LP: #1031065
|
|
|
|
|
|
LP: #1018554
|
|
This just updates upstart jobs to the new single binary approach.
|
|
LP: #861866
|
|
|
|
This should not happen any time in the near future, but /var/run
is actually legacy, so accept that it might not be there.
|
|
|
|
This continues the change in this file that intended to wait
for all networking to be up. The logic that was there would
cause it to start cloud-init immediately if a single non-lo
interface was up.
This will basically just check if 'static-network-up' has occurred
during this boot.
There could be an issue if /var/run was populated from a previous
boot, but since its really expected to be a tmpfs, can't have anything
in it.
|
|
LP: #810044
|
|
LP: #800824
|
|
|
|
to console on missing file
|
|
LP: #714807
|
|
|
|
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
|
|
instead of hard-coding in cloud-init-cfg the module list that should be
read, read it from the second command line argument. Basically, instead
of reading 'cloud_config_modules', specify 'cloud_config' when
cloud-init-cfg is run.
change the upstart job to invoke cloud-init-cfg with:
exec cloud-init-cfg all cloud_config
rather than
exec cloud-init-cfg all
|
|
Now, in addition to running instance specific scripts (in runcmd or
user-data scripts), cloud-run-user-script will run other directories
also. All under /var/lib/cloud, and in the following order:
scripts/per-once [once ever]
scripts/per-boot [every boot]
scripts/per-instance [once per instance]
instance/scripts [once per instance]
At the moment, the marker is on the entire directory, so changes to that
directory. Changes to the contents of the directory will not be noticed.
|
|
Previously, if you ran an instance with either runcmd data or user-data
scripts, it would run again after rebundle or create-image.
This puts the files created by runcmd or user-data scripts into instance-id
specific paths, and then runs them by that instance-id specific path.
LP: #675711
|
|
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.
|
|
|
|
|
|
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
|
|
cloud-config. Doing so means the collision that was occuring with
upstart/mountall will not occur. However, it also means any mounts
configured will not be mounted until later. LP: #527825
LP: #527825
|
|
Some changes were rushed in prior to lucid beta that didn't get pulled
back into the upstream release. I'm pulling those in here.
|
|
cloud-config-misc is adding a script to the directory
where user-scripts go, so run-user-script has to wait on it.
|
|
|
|
LP: #523625
|
|
cloud-run-user-script was never running because it depended on
'stopped cloudinit', rather than
'stopped cloud-init'.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This fixes LP: #506599 , LP: #507070 .
Also, here, we move config parsing out of the EC2Init class.
Instead the parsing of /etc/ec2-init/ec2-init.cfg is now done in the
CloudConfig class, and prepended to the cloud-config that comes in
from user data. This means that values in user data will over-ride
the settings in /etc/ec2-init.
Still TODO is support reading the public and private key files from
the cloud-config
|
|
|
|
At this point, the following should be functional:
cloud-init-cfg apt-update-upgrade
|
|
1. arguments to run-parts came before run-parts
2. explicitly state that we dont want this script to run
until cloud-config is done
|
|
|
|
run-parts didn't like scripts ending in .sh apparently.
the man page says:
If neither the --lsbsysinit option nor the --regex option is given
then the names must consist entirely of upper and lower case letters,
digits, under‐ scores, and hyphens.
We dont want to have such a restriction. so run with
--regex '.*'
Second change is making this run once-per-instance .
|
|
bzr+ssh://bazaar.launchpad.net/~zulcss/ec2-init/ec2-init-config/
|
|
|
|
|
|
supports user data as mime-multipart and handling types of
text/x-shellscript - execute at rc.local
text/cloud-config - feed to cloud config
text/upstart-job - add to /etc/init as upstart job
text/x-include-url - include urls as if they were in-line
|
