| Age | Commit message (Collapse) | Author |
|---|
|
At this point, the following should be functional:
cloud-init-cfg apt-update-upgrade
|
|
|
|
For user data that is not a mime message, we were not applying the
starts with rules. In fact, they were not getting applied at all.
Other fix here is to have the 'main' function decompress input
|
|
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/
|
|
|
|
|
|
There are some problems with boto 1.9, (eucatools has issues with it).
For now, I'm copying the portions of boto that i needed here to boto_utils.
This gets me the newer get_instance_metadata() without needing boto
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
write-mime-multipart text/x-shellscript path/filename.sh \
text/x-cloud-config my.yaml \
> my.userdata
|
|
|
|
adding cat-cloud-config.conf, a debug file that just cats the config
|
|
cloud-init-run-module handles some boilerplate code for running
items on a 'frequency'. It has the following usefulness
- a config module can be put into ec2init dir and implement a 'run'
method that takes a list of arguments and the path to a config file
- it handles invoking module.run() only at a given frequency
This is similar to karmic's ec2init's "run_once_ever" or run_once_per_ami
execute.py is an example module that executes the arguments given to it
An example usage in an upstart job would be with a 'exec' line like:
exec cloud-init-run-module once_per_ami clean-core execute rm /var/run/core
The above would then run the command 'rm /var/run/core' only once
|
|
|
|
|
|
|
|
|
|
|
|
this 'install.sh <dir>' script ends up rendering a directory structure
under <dir> like would be packaged in a deb
|
|
|
|
|
|
|
|
I'm saving ec2init.conf.goal off as the goal. At some point in the
future that should be functional.
ec2init-disable.conf is present as a debugging tool. If boot hangs
due to unsatisfiable conditions in start-on for ec2init.conf, this will
disable ec2init.conf so a reboot will come up ec2init.conf running.
|
|
|
|
|
|
This commit merges
lp:~soren/ec2-init/0.5 at rev 67
and lp:ubuntu/lucid at 0.4.999-0ubuntu8
|
|
This is a speed improvement as previous would make a fork/subshell for
each pipe. This will only make a single fork. I've also verified that
each line in logger output will still get the 'ec2' prefix
$ printf "%s\n%s\n" "hi world" "by world" | logger -s -t ec2 2>/dev/null
$ tail -n 2 /var/log/messages
Sep 24 19:06:10 ip-10-242-225-190 ec2: hi world
Sep 24 19:06:10 ip-10-242-225-190 ec2: by world
The other thing to note is that I redirected stderr of the
regenerate_ssh_host_keys call to logger, so it will go to the logs also.
|
|
|
|
|
|
|
|
actually offer.
|
|
This gives us the bulk of the magic needed on the instance side
to implement http://wiki.ubuntu.com/VirtualApplianceSpec
|
|
|
|
This can either be invoked by instrumenting the user-data with a mime
part with content-type 'text/x-ebs-mount-description' with a body like
so:
device=/dev/sde:/var/lib/mysql,/etc/alfresco
device=/dev/sdf:/other/things
or by using the appliance config XML format like so:
<appliance>
<storage device="/dev/sde">
<path>/var/lib/mysql</path>
<path>/etc/alfresco</path>
</storage>
<storage device="/dev/sdf">
<path>/other/things</path>
</appliance>
</appliance>
In either case, if the volume does not yet have a filesystem, one will be created.
For each path that is to live on the volume, a directory is created, and
populated with the data currently in the target directory (e.g.
/var/lib/mysql is copied to ${ebs_volume_path}/_var_lib_mysql). Once
this is done, the directories are bind-mounted to the relevant paths.
If the directories in question already exist, they will just be bind-mounted.
|
|
Add @handler decorator for appliance config
|
|
LP: #376740
|
|
Added test cases for this.
|
