Pete,
What problem were you seeing exactly?
The upstart jobs cloud-* do not explicitly list 'cloud-config' as a 'start on' requirement. That is by design. cloud-init starts on:
(mounted MOUNTPOINT=/ and net-device-up IFACE=eth0)
That set of events actually blocks any other upstart jobs from running until it is finished. Because of this, all the other cloud-config-* jobs are guaranteed to run after cloud-init finishes. Your suggestion to modify that to 'filesystem' from 'mounted MOUNTPOINT=/' will break that.
Have you actually seen this to not be true ?
I do agree that the parallelization of the cloud-cfg jobs is annoying. This has been changed in maverick. Now the jobs run serially, and the order can actually be controlled by cloud-config input.
For the case that you were interested in, with the debconf, the setting of debconf values will run prior to the running of 'apt-get' so that should be fine.
The one thing I would consider most annoying is that user scripts (upstart/cloud-run-user-script.conf) are not guaranteed to run after any of the cloud-config jobs are run. So, you can't rely on the following cloud-config:
| #cloud-config
| packages:
| - axel
| runcmd:
| - [ axel, http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.35.tar.bz2 ]
I find that to be annoying, and would agree to fix that.
Pete,
What problem were you seeing exactly?
The upstart jobs cloud-* do not explicitly list 'cloud-config' as a 'start on' requirement. That is by design. cloud-init starts on:
(mounted MOUNTPOINT=/ and net-device-up IFACE=eth0)
That set of events actually blocks any other upstart jobs from running until it is finished. Because of this, all the other cloud-config-* jobs are guaranteed to run after cloud-init finishes. Your suggestion to modify that to 'filesystem' from 'mounted MOUNTPOINT=/' will break that.
Have you actually seen this to not be true ?
I do agree that the parallelization of the cloud-cfg jobs is annoying. This has been changed in maverick. Now the jobs run serially, and the order can actually be controlled by cloud-config input.
For the case that you were interested in, with the debconf, the setting of debconf values will run prior to the running of 'apt-get' so that should be fine.
The one thing I would consider most annoying is that user scripts (upstart/ cloud-run- user-script. conf) are not guaranteed to run after any of the cloud-config jobs are run. So, you can't rely on the following cloud-config: www.kernel. org/pub/ linux/kernel/ v2.6/linux- 2.6.35. tar.bz2 ]
| #cloud-config
| packages:
| - axel
| runcmd:
| - [ axel, http://
I find that to be annoying, and would agree to fix that.