| Age | Commit message (Collapse) | Author |
|---|
|
Now, instead of setting a default value in cloud-init based only on the
DataSource, this supports using 'locale' in the cloud-config.
|
|
Instead of:
root=LABEL=uec-rootfs ro console=hvc0 ssh_import_id=smoser
We now have more generic:
root=LABEL=uec-rootfs ro console=hvc0 cc:ssh_import_id: smoser
|
|
This allows the user to specify portions of the cloud-config
system config on the kernel command line. values found on the
kernel command line have preference over those in system config.
The format is:
cc:[ ]<yaml content here> [end_cc]
Where:
'cc:' indicates the beginning of cloud config syntax
[ ] optionally followed by whitespace (which will be trimmed)
<yaml content here> :
this content is passed untouched to yaml
end_cc:
this is optional. If no 'end_cc' tag is found, all data from
the begin tag to the end of the command line is consumed
Multiple occurences of the cc:<data>end_cc will be joined with
carriage return before passing to yaml.
Any litteral '\n' (backslash followed by lower case 'n') are converted
to a carriage return.
The following are examples:
cc: ssh_import_id: [smoser, kirkland]
cc: ssh_import_id: [smoser, bob]\\nruncmd: [ [ ls, -l ], echo hi ] end_cc
cc:ssh_import_id: [smoser] end_cc cc:runcmd: [ [ ls, -l ] ] end_cc
|
|
This set of changes makes '/etc/cloud/cloud.cfg' support "#include"
and "#opt_include". The idea is to then provide a base configuration
and allow distro or local changes that would override that.
|
|
|
|
|
|
|
|
VPC instances cannot reach other hosts in EC2 (such as the archives).
In this case, use the default mirror instead.
LP: #615545
|
|
|
|
|
|
LP: #623609
|
|
|
|
for 'mounts' entries that yaml interprets as integers, we need
to be strings. This is because of he 'join' that is used on the array.
For example:
mounts:
- [ ebs1, none, swap, sw, 0, 0 ]
was throwing error when the array was joined.
|
|
|
|
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".
|
|
This means that if you booted an ebs instance with a ephemeral0 device
and then stopped it and modified its type to be one that did *not* have
an ephemeral0 device, you'd still have the entry, but it wouldn't block
boot.
LP: #634102
|
|
|
|
LP: #632744
|
|
|
|
|
|
Previously,
apt_sources:
- source: source1
- source: source2
resulted in source1 being written to
/etc/apt/sources.list.d/cloud_config_sources.list , and then
that being overwritten by source2.
This definitely is not expected.
Instead, in all cases now, (including 'filename:' cases), just append.
LP: #627597
|
|
LP: #627439
|
|
LP: #620572
|
|
|
|
if 'base' input to reed_seeded contains a "%s", then substitute
'user-data' and 'meta-data' at that location rather than at the end.
Ie:
- base="http://foo.bar/"
userdata_url = http://foo.bar/user-data
metadata_url = http://foo.bar/meta-data
- base="http://foo.bar/%s?user=smoser"
userdata_url = http://foo.bar/user-data&user=smoser"
metadata_url = http://foo.bar/meta-data&user=smoser"
|
|
All other marker files by cloud-init live in /var/lib/cloud/sem
it makes sense for uncloud-init's file to live there too.
|
|
LP: #617400
|
|
This was causing failure in debian packaging.
|
|
|
|
|
|
|
|
This just records in 'self.seedfrom' each of the locations that
seed data was read from.
|
|
get_data was returning True before it set self.user_data_raw and
self.user_data.
|
|
|
|
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
|
|
read_optional_seed should return true or false based on whether or not
the seed existed. It is useful to easily say read this if its there,
but it might not be.
|
|
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
