An EBS-backed AMI that was just a shell looking for a spacewalk/satellite server for guidance on what to become (or listening to an SQS queue for info on what to build, or....etc etc) is the next matter. The biggest question is then that: where it is you want to get that info about the type of install to then do?
lemme be more clear:
Need: a functional replacement for the old use these two types of cases:
1) turning on a machine with PXE-boot that then builds itself magically to what it is you happen to need
2) a machine that has a tiny bootable CD that knows to look on the network at magical location X for either the entire kickstart file, or uses a kickstart file on the CD that then sources to network locations to flesh out contents of the kickstart.
So, having an AMI that works that way...
1) hard code it to look for whatever happens to be sitting at location X for a kickstart file?
2) Have it start up a basic environment that sources to X location for more info?
3) Have the kickstart file have various logic, and the decisions for the logic be based on:
3-1) "user-data" info passed during image creation?
3-2) info available at a url? Ie, check "ec2master.guardis.com/nextec2type" for a simple answer?
3-3) have kickstart join a queue system of some sort (SQS, AMQP, whatever) and get info about what to do from the queue?
4) have a spacewalk/satellite server tell the bare-metal install-boot what to do next?
Yeah, it's something I think I'll sit down and solve relatively soon; I realized I'm not actually satisfied with making an AMI for each type of role and then just launching that AMI. That poses, in my mind, too many problems...problems that prompted the solutions that have been in place within datacenters for many years already - be it kickstart servers, jumpstart servers, software depots, wsus servers...these centralized solutions for taking a bare installation image and installing whatever you need next are clearly out there for physical datacenters. They weren't made in an absence of need.
So...how then to do those same use cases "in the cloud?" Do we....need to? It seems to me to be an effort worth exploring, but...maybe not?
Whatever the case, we haven't even defined a spec, much less has anyone solved the problem yet - that I've seen, at least. Though we might have been able to get a POC during a few hour hackfest this past weekend, maybe ;)
Brian
2011/1/31 Raphaël De GIUSTI <raphael.degiusti@xxxxxxxxxxx>
Brian, I would appreciate it. Where can I get feedback from this ?Michael,Here's a tutorial for a Centos 5.5 install I found very useful :As for automating the building of Centos 55 and Fedora 14 instances, there's the ami-creator from Jeremy Katz that's closer to what I'm looking for as you put a kickstart in and an ami pops out :Here is his blog post about ithttp://velohacker.com/fedora-notes/announcing-ami-creator/
On Fri, Jan 28, 2011 at 8:58 PM, Michael Howard <michael@xxxxxxxxxxxx> wrote:2011/1/28 Raphaël De GIUSTI <raphael.degiusti@xxxxxxxxxxx>:
> Hi everyone,I have been looking for this kind of information, but not having much luck.
> I've been playing around with Amazon EC2, building my own Centos and Fedora
> EBS backed AMI's without much trouble, following tutorials and other
> practices I found on the internet.
Any pointers / URLs to building EBS-backed AMIs for Fedora & CentOS
would be appreciated.
Thanks,
Michael
_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud
_______________________________________________
cloud mailing list
cloud@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/cloud
_______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud
