| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
new preferred config file /etc/cloud/cloud.cfg.
cloud.cfg is read, its values are overridden by the cloud-config data
from user data
|
|
This fixes LP: #506599 , LP: #507070 .
Also, here, we move config parsing out of the EC2Init class.
Instead the parsing of /etc/ec2-init/ec2-init.cfg is now done in the
CloudConfig class, and prepended to the cloud-config that comes in
from user data. This means that values in user data will over-ride
the settings in /etc/ec2-init.
Still TODO is support reading the public and private key files from
the cloud-config
|
|
|
|
|
|
LP: #506332
|
|
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.
|
|
|
|
|
|
|
