| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
At this point, this is appears much like a cripped 'ec2metdata' tool.
However, it does provide a tool interface to some fields independent
of their DataSource.
|
|
When the user attempts login as root, they see a message suggesting
a different user. This changes that message from:
Please login as the ubuntu user rather than root user.
to
Please login as the user "ubuntu" rather than the user "root".
LP: #672417
|
|
This will allow this code to be called more easily elsewhere.
I'm considering having the "all the way up" message contain fingerprints
so that they're more or less guaranteed to get to the console where
the user could see them.
|
|
This adds the following cloud-config keys:
- 'rsyslog_dir' default: /etc/rsyslog.d
- 'rsyslog_filename' default: 20-cloud-config.conf
- 'rsyslog' (list) default: empty
|
|
|
|
Previously the 'get_locale()' method of DataSourceEc2 would select
a default locale based on the availability zone that the instance was
running on.
I generally don't like that as
a.) there are loads of other locales than en_US and en_GB (that were being
used)
b.) either one is almost certainly not really the users preferred locale.
Just because I launch an instance in eu-west-1 doesn't mean I perfer en_GB.
|
|
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
|
|
|
|
|
|
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
|
|
|
|
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"
|
|
LP: #617400
|
|
|
|
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.
|
|
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
|
