| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
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.
|
|
|
|
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
|
|
|
|
In starting containers in lxc, I was seeing errors like:
/proc/self/fd/9: 24: kill: No such process
Which indicated the sleep pid had already died.
I'm not sure how or why it was dead, but this just is less annoying in that
case.
|
|
|
|
LP: #1015223
|
|
ifquery will exit failure if there is no /run/network directory.
normally that would get created by one of network-interface.conf
or networking.conf. But, it is possible that we're running
before either of those have.
|
|
|
|
|
|
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'.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
