Kickstart a Fedora (Anaconda) Install on EC2
Jeremy Katz
katzj at fedoraproject.org
Wed Feb 2 20:48:00 UTC 2011
On Wed, Feb 2, 2011 at 3:42 PM, Garrett Holmstrom
<gholms at fedoraproject.org> wrote:
> On Wed, Feb 2, 2011 at 10:19 AM, Brian LaMere
> <brian at 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
More information about the cloud
mailing list