| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
add 'hostname' cloud-config option for setting hostname
make rsyslog and resizefs run at cloud-init time
|
|
|
|
|
|
|
|
LP: #653220
|
|
|
|
since user names and group names wont' be the same on all images,
allow configuration of what ownership to put on 'default_log_file'.
|
|
add caching of the parsed config, this will allow re-use in cloudinit
so that we don't have to load the default config more than once in
a program.
|
|
|
|
cloud-config-archive is a yaml formated document where the top
level should contain an array. Each entry in the array can be one of
- dict { 'filename' : 'value' , 'content' : 'value', 'type' : 'value' }
filename and type may not be present
- scalar(content)
if filename and type are not present, they are attempted to be guessed.
LP: #641504
|
|
|
|
- /var/lib/cloud is redesigned, and its layout now described in
doc/var-lib-cloud.txt.
The big plus point of this was to get instance specific data
into /var/lib/cloud/instances, so that data could easily be purged.
A symlink /var/lib/cloud/instance -> /var/lib/cloud/instances/<current_id>
is maintained.
- Also, now run scripts in /var/lib/cloud/scripts/
per-once
per-boot
per-instance
- bugs addressed:
- LP: #704509
|
|
|
|
|
|
This change just uses a different facility for coming up with the path.
But, by design I'm chosing to put 'previous-hostname' in
/var/lib/cloud/data/
rather than in
/var/lib/cloud/instance/data/
The idea is that if the user:
- started an instance
- modified /etc/hostname
- bundled instance (or create-image from it)
- started new instance
They would expect their modified /etc/hostname to persist. As such, the
previous-hostname file should be cross-instance data.
Bugs in this area include LP: #596993 and LP: #514492
|
|
|
|
- cloud_config and scripts now live in instance directory
- cachedir is now more correctly named 'seeddir'
|
|
|
|
|
|
|
|
|
|
LP: #704509
|
|
|
|
sources can use $MIRROR and $RELEASE and they will be replaced
with the local mirror for this cloud, and the running release
this:
- source: deb $MIRROR $RELEASE multiverse
would possibly be turned into:
- source: deb http://us-east-1.ec2.archive.ubuntu.com/ubuntu natty multiverse
LP: #693292
|
|
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.
|
|
|
|
|
|
|
