On Wed, Feb 2, 2011 at 3:42 PM, Garrett Holmstrom gholms@fedoraproject.org wrote:
On Wed, Feb 2, 2011 at 10:19 AM, Brian LaMere brian@cukerinteractive.com wrote:
Right, it's entirely ephemeral AMIs at this point. Unfortunately, doing more is somewhere between tough and impossible in a sane way as there isn't really a good API for uploading an EBS backed AMI. It's all "dd onto a block device, snapshot, foo".
yeah, that's why although my silly script is ugly it still produces the right result; an AMI that can be used for EBS-backed stores, of an image that has never run and is free of such taint. How one gets to there is important, but considering it's not something that gets repeated often (once you have an AMI, the AMI is done...) the real issue is what the end result ended up being.
At FUDCon I heard that rawhide's version of anaconda can install directly to things like disk images and block devices, IIRC. Maybe that would be useful.
Unclear. The pendulum is swaying back towards putting the pieces into anaconda when they were pulled out from anaconda and into python-imgcreate/livecd-creator ~ 5 years ago ;) There are arguments both ways and I've even argued both of them over time :-)
Maybe I'm missing something: why would you ever want an instance to kickstart at boot time? You should create an image for every role you care about and then boot the appropriate one for every instance you need.
For the exact same reason that you ever kickstart a machine vs using some imaging technology -- flexibility. You can generate a kickstart config by a CGI and have a virtually infinite number of combinations. You can't store an infinite number of images (obviously) and even storing a lot of images becomes costly. Even at EC2 prices.
- Jeremy