Hi Russ,

I think you'll find it hard to get any traction here kickstarts especially in the "cloud front" are used increasingly less in favour of bootstrapping an instance with  puppet / chef for provisioning above and beyond the base os.

The tdl format is somewhat of a stop gap between kickstarts and fully fledged provisioning I have found, and a good project providing many example tdls is the Aeolus project: http://www.aeolusproject.org/

Myself I have gone the way of kickstarts -> boxgrinder -> oz -> puppet.

Also of note, puppet manifests as they use a ruby DSL version control very well, I can not vouch for chef however.

Cheers

David




On Tue, Dec 18, 2012 at 4:15 PM, R P Herrold <herrold@owlriver.com> wrote:
in the IRC channel, I am advised by 'msavy' that Boxgrinder is on a path to end as a project, and transition into:
        http://imgfac.org/

which uses underneath: oz
        https://github.com/clalancette/oz

Seemingly also, the former (and somewhat broken) appliance-creator goes away

My goal is to be able to get to an TUI tool:
        image building image
that accepts kickstart config files as input, and emits runnable new images of various type, and it looked as though I could graft on the needed elements to Boxgrinder.  There is a lot of churn, for example on the Fedora 'cloud' sig mailing list, and on corresponding Debian list, on what to include, or exclude from pre-built cloud images.

I think those 'cloud' working groups are solving the wrong problem at the wrong place, [some want JEOS to include a listening sshd, and package install tool; others want rsync, or man, or more, or less ... the preferences never end and there is no 'right answer']

An:
        image building image
decouples those design preferences and moves solving those issues into a flat text specification ( a 'ks.cfg', etc) that will work well in a version control system (unlike using a GUI front end which does not)

-- Russ herrold