On Wed, Feb 2, 2011 at 3:42 PM, Garrett Holmstrom <gholms@xxxxxxxxxxxxxxxxx> wrote: > On Wed, Feb 2, 2011 at 10:19 AM, Brian LaMere > <brian@xxxxxxxxxxxxxxxxxxxx> 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 cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud
