<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Right, it's entirely ephemeral AMIs at this point. Unfortunately,<br>
doing more is somewhere between tough and impossible in a sane way as<br>
there isn't really a good API for uploading an EBS backed AMI. It's<br>
all "dd onto a block device, snapshot, foo".<br></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">front. In terms of keeping things relatively consistent with a normal<br>
install path, the path of least resistance is probably just sticking<br>
what would be kernel command line params in user data and then having<br>
anaconda know to look there if it notices it's running in EC2. Then<br>
you can install to your EBS volume, reboot and voila.<br></blockquote><div><br></div><div>Yup, no reason "curl <a href="http://169.254.169.254/2009-0404/user-data/">169.254.169.254/2009-0404/user-data/</a>" couldn't respond with "BUILD_ROLE=lamp" with kickstart doing logic based on such, or how ever else one would want to do it. Could even lists the package groups and individual packages right there, as well as where to find root and such. The requisite tools all exist, they just need someone to put them all together. Sounds like Jeremy is volunteering! ;)</div>
<div><br></div><div>Brian</div></div>