On Fri, Feb 26, 2010 at 9:32 AM, David Huff <dhuff at redhat.com> wrote: > I agree with both of you, this is why we need to focus providing a way > to reproducible build pre-installed images that can then be adapted to > each a target infrastructure. Luckily, we have a great way to build pre-installed images with a kickstart file combined with one of the tools which transforms them into "a system", whether it's anaconda or something based on python-imgcreate :) > Jeremy is right, "you *can't* have one image that supports multiple > providers," however you can have separate ks files for each provider and > a standard build process. This is why I tried to put all the EC2 > specific configuration in to the ks file not in the tool that build the > images. I'm back and forth about sticking these provider specifics into the kickstart config vs actually in the toolset. There are advantages each way. One really nice thing about keeping them out of the kickstart config is that the same config can be used across *all* of the kickstart-consuming tools rather than doing something like mainimage.ks and ec2.ks, rackspace.ks, etc all with a %include of mainimage.ks. The flip side is that by having it in the kickstart config like the above, it's easy for someone to take and quickly get it working for another provider's bizarre design choices which make you go "wtf?" ;) - Jeremy
