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