On Fri, Feb 26, 2010 at 9:32 AM, David Huff <dhuff(a)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