On Tue, Dec 18, 2012 at 11:15 AM, 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
Seemingly also, the former (and somewhat broken) appliance-creator goes away
appliance-creator going away is somewhat separate, because (as I'm
told) it's functionality is being rolled into lorax, which more
tightly couples it to anaconda. For your desired kickstart-based
approach to image building, which I also prefer, there may be some
merit to doing this.
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']
+1 ... those conversations are mostly just bikeshedding. In an ideal
world, users will be comfortable enough with image building that
having an "official" image will be mostly meaningless. I think that
the world of cloud users isn't quite there yet, for whatever reason.
What we provide them as a default image in the meantime should be a
useful set of packages, not an absolutely minimal one, but that's the
not goal being pursued.
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)
To be fair, the GUI front-end could be creating text artifacts and
shoving them into a version control system; that's exactly what
rPath/rBuilder did years ago, and I suspect SuSE Studio does as well.
I haven't looked at Image Factory yet, but if it's not doing this, I
suspect it won't be interesting to very many people. Also, FWIW, the
reason given on the cloud list for the move toward oz was the need to
build images for other OSes and distros. The requirements of a tool
for cross-distro image builds is quite different from what you (and I)
want, and I'm actually happy to see them be clearly separated, to be
honest. Today I happily use ami-creator, and someday I may happily
use lorax; I'm simply not the target audience for Image Factory / Oz,
and that's okay.
Andy
-- Russ herrold
_______________________________________________
cloud mailing list
cloud(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud