On Wed, Feb 2, 2011 at 3:42 PM, Garrett Holmstrom <[email protected]> wrote: > On Wed, Feb 2, 2011 at 10:19 AM, Brian LaMere > <[email protected]> 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 _______________________________________________ cloud mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/cloud
