cloud-config / cloud-init support for ami-launch-index
right now, nothing in cloud-init or cloud-config allows for instances to differ. If launched with --instance-count, then all instances will be the same. cloud-config could easily support this by using a 'instances-cloud-config' section in yaml. for cloud-init, it might require using archive format (currently multipart mime).
better use of instance after test-multi is done
The iso tracker test instances are thrown away minutes after their started. We pay for the whole hour. It would only make sense to see what else we can do with those resources, and then shut down the instance safely before the 1hour mark.
Some thoughts are:
running load or network tests: this would possibly allow us to catch issues like 574910
EBS Root AUFS storage location
Similar to many of the live-cds that provide persistant storage to a usb key using a union filesystem, an EBS volume could be used as the write location for a AUFS union mount. This would differ from above, as the EBS root would only need to be big enough to provide delta storage, reducing the cost.
[Update 2010-02-24] With "Real EBS boot", this is much less valuable. Additionally, cost of EBS is probably small enough to make interest in this minimal.
Auto Consumption of EBS Volumes
It would be good if the ubuntu uec images were capable of "find"ing a EBS volume with some identification data on it and automatically use that as the root device. More generically, the uec images could support searching disks for well-known/well-formed data early in the boot cycle and "consuming" those disks. "Consuming" may refer to:
- mounting disk to location specified
- mounting the disk and executing arbitrary code
- mounting the disk and pivot_root'ing to it.
A well done solution might enable a vendor to ship a cloud solution as a EBS volume that used un-modified official ubuntu images.
"well-known/well-formed" might refer to disks that had an identifying file in the root of their filesystem (ie 'ebs-config.txt'). The boot process would mount (read-only) all filesystems it found and look for such configuration information.
Restricting access to user/cloud instance data
- Implemented in lucid via cloud-config disable_ec2_metadata: true
EC2 instances are provided with a metadata information at http://169.254.169.254 . This information includes 'user-data' and possibly other data that might be sensitive. Access to that data is not at all restricted. Any user (non-root) can access that information.
One way to restrict access to this metadata would be to crawl it early in boot, and then use iptables to block access to the specified network address. The crawled data could be stored in /var/run/ec2 (or approprate place) and normal filesystem retrictions can be enforced.
Currently, the ubuntu images generate the public/private sshd server keys on first boot using 'ssh-keygen' . The fingerprint of these keys are written to the console, and the user can then read the console output to verify the randomly generated key. The above solution would give similar levels of protection to that data from inside the instance.
User Controllable "Run-per-X"
Right now (lucid) the CloudConfig class knows how often things are supposed to be run. Most of this is "once-per-instance". With EBS root, the decision was initially made to still run "once per instance", even though user data could change.
It would be possible to allow the user, in user data, to specify the when things shoudl run. This would allow a user to override "config-mounts" and have it run on every boot. Changing config-mounts to run every boot would make cloud-config correctly re-write /etc/fstab if 'ephemeral0' changed.
Implemented in maverick cloud-init.
EBS Root Support
Amazon's Elastic Block Store (EBS) provides for persistent block level storage. This storage can be used as a root device to provide a system that can be terminated and re-constituted without losing its state. There is an example of how to do this.
Note, the link above treats the ami-image much like a large initrd. Essentially it finds the EBS device and pivot_roots to it. This is definitely something that could be achieved within an initrd.
[Update 2010-02-24] As "Real EBS boot" is now available from amazon, this is less useful here. However, the approach may still be usable in UEC where there is no EBS boot support.