future of Boxgrinder ... building cloud images

[Andy Grimm]

On Tue, Dec 18, 2012 at 11:15 AM, R P Herrold <herrold at 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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/cloud