Resurrecting BoxGrinder, help wanted!

[serverchief]

We would like to resurect BoxGrinder,

Please respond if you would like to join on development efforts.

Thanks

ilya

[dhartford]

I am very insterested in what Boxgrinder was trying to accomplish!

However, the particular skillsets needed are not necessary an area I personally am not strong in (knowing operating systems, virtualization platforms, cloud platforms, and I think Ruby(?)).  What I can do to help :-)

[herrold]

The problem with 'Resurrecting BoxGrinder' is that the folks formerly running the project have moved to later _viable_ approaches.  Not that Boxgrinder was not viable in its day, but the CI, and commit rights into VCS's that feed those CI engines, are not accessible  A workaround is to 'fork' and set up a new project, unless the 'keys' for managing the old infrastructure can be obtained

[serverchief]

So i looked for other viable approaches, i've tried so many different projects - none of them as as smooth and easy to work with as BoxGrinder.

We can fork the repo on github and take it from there. We can rebrand this project if need be and give it new life.

If interested, just leave a comment here and we will take it from there.

[goldmann]

Hey,

First of all - I'm not the BoxGrinder project leader anymore (since June 2012). Everything you read below is my personal idea, not as the project leader.

It's true that the project is not developed actively these days. I was pulled in work related with WildFly and Fedora, Marc is busy with productization stuff now. We don't have much time to work on this nice project.

I am personally happy if someone could help us maintain this project. If you have any pull requests, just start sending them. I can review them and include in the base package and if the code quality would be good enough - I could even grant access to the repository. If you're interested in the development of BoxGrinder - please sign up to the BoxGrinder develeloper mailing list and start a discussion about things you want to see or bugs that need to be fixed. Since we're busy now - mailing list is way better than IRC atm. We can answer your code-related questions there.

BoxGrinder is written mostly in Ruby. Some Ruby knownledge would be nice before you start working on this project A Fedora knowledge would be good too, but you can learn it while resolving bugs related to image creation. It's not as hard as you may think.

The most problematic piece of code in BoxGrinder is the appliance-creator usage. This is the main builder we use underneath (written in python). This project is not developed actively since a couple of years now. Some people still maintain it, since this is a pretty important piece of software, but is not very flexible, sadly.

Regarding CI - I'm the admin of this piece of infrastructure. If there will be some requests - please let me know. I'll try to help.

I would advice you to not fork this project and try to help (if you want) to save the BoxGrinder brand.

Thanks!

[ryanuber]

Hey Marek,

Thanks for replying here. Glad to hear that you are willing to accept contributions on BoxGrinder.

I'd be interested in helping where I can in maintaining BoxGrinder.

I believe the most valuable piece of BoxGrinder is its core functionality. The delivery plugins are a great convenience, but understandably a lot of those interfaces are changing quickly as new cloud technology comes about. I have spent a bit of time in boxgrinder-build. I am mostly a RHEL user, and I've worked with RPM, YUM, kickstart, libguestfs etc. I've written a few open source Ruby programs before, and worked quite a bit with Puppet (also Ruby).

We use BoxGrinder where I work and we have now gotten to a point where BoxGrinder just can't do what we need without a few patches here and there. Rather than trying to maintain it internally (we are doing this now), or forking it, I am interested in hearing feedback on patches I've written and getting consensus from the people who still actively use BoxGrinder, and eventually merging changes in when they are agreeable / tests pass / etc.

I currently have 5 PR's waiting for boxgrinder-build, all of which are bug fixes. Here's hoping that the community picks up again.

[alopgeek]

As a somewhat dissatisfied boxgrinder user, What are the more viable alternatives that exist today?

Any favorites?

[ryanuber]

This is fairly promising and currently very active:

http://www.packer.io/

I would probably start with packer.

I have also tried imagefactory

https://github.com/aeolusproject/imagefactory

However, I found it to be far less useful than Boxgrinder.

[dhartford]

Following up, my own research notes for alternatives to boxgrinder (the term I use is 'image builder'):

•   Suse Studio: http://susestudio.com/

• Image Factory http://imgfac.org/,  http://www.aeolusproject.org/imagefactory.html

  • discontinuing: http://blog.aeolusproject.org/a-note-about-aeoluss-direction/

• VMBuilder: https://launchpad.net/vmbuilder

• Vendor/virtualization engine specific tools

  • Xen, VMWare, etc all have individual image builders that are specific/custom to them.

  • Windows images, for example, can be created using Xen image creation tools…but usually just the base OS without updates or additional software.

• other ones: http://docs.openstack.org/trunk/openstack-compute/admin/content/tool-support-creating-new-images.html

• Vagrant: Probably not production quality images, but another option: http://www.vagrantup.com/

  • Boxgrinder has been referenced to create the base 'boxes' used by Vagrant…vagrant is kind of an in-between more than an image builder.

• Packer.io: http://www.packer.io/
  • lacking xen support (2012)
    

-----------------------------------------------------

There is little that is comparable to the 'full suite' that boxgrinder offers, only projects that may be 'good enough' for specific constraints/scenarios. 

In a hope to re-establish what I like about Boxgrinder and/or where I thought it was heading:

• Select a base os/distribution (preferably with option to select a remote ISO or similar location for automation, or ready-to-go templates with all resources/references ready to go).
• Create a custom 'filesystem' when appropriate (current somewhat deficiency in boxgrinder, for example squashfs/live versions)
  • ignorance here around 'cloud' versus virtualization filesystem/storage (amazon ebs/etc).
• Add additional packages (RPM), or remove packages from the base os/distribution
  • create a template of the above configuration, and allow inheriting.
• Post-script support for additional configuration/setup (could be done as 'configuration' rpm).
  • This is where appliance creators would quickly adopt boxgrinder when used with the image creation options.
• conversion to an 'image' for an appropriate platform to *either* cloud or virtualization solution...and I'll add a third, 'desktopvirt'.
  • cloud: amazon
  • cloud: openshift  (or private cloud:openshift)
  • cloud: openstack
  • virt: xen
  • virt: kvm
  • desktopvirt: vmplayer
  • desktopvirt: virtualbox
  • ???livecd usb image/bootable iso?
• delivery of image, when relevant/appropriate (for myself, this is low priority)
  • direct deployment to amazon/openshift/etc.
  • ??? delivery to 'image' store (either the iaas/paas 'image' repository, or maybe another form of image repository for use with other delivery mechanisms used by enterprises?)

[kernelsmith]

I'm interested in helping revive BoxGrinder.  Ruby is my best language and I'm quite familiar with most virtualization technologies, except OpenStack , especially all VMware products, VirtualBox, even some QEMU if you want to lump it in.  I'm also an RHCSA, tho it's on RHEL 5 and my Xen knowledge has dwindled a bit since then.  You can check out my github page for some of the stuff I work on and follow.  Metasploit is my most active Ruby project, I was even granted commit rights there.

A nice place to start would be fixing the broken download links for the meta appliance.

Oh, I also overhauled the ghetto-esxi-linked-clones shell script from virtually-ghetto a while back env-customization/esxi/ghetto-esxi-linked-clones.sh at master · kernelsmith/env-customization · GitHub  If one has ssh access to an esxi server, one can make multiple linked clones from a "gold-standard" VM using the script and choose whether to leave them powered up or down, collect mac addresses, add VNC, adjust the firewall etc.  ESXi is also where my main interests lie at the moment, but I like to stay on the free (as in beer) side.