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(a)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<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