On Wed, Feb 2, 2011 at 3:42 PM, Garrett Holmstrom
<gholms(a)fedoraproject.org> wrote:
On Wed, Feb 2, 2011 at 10:19 AM, Brian LaMere
<brian(a)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