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