On Thu, Jul 12, 2012 at 4:32 PM, Chip Childers <chip.child...@sungard.com> wrote: > I've been working on encapsulating the DevCloud configuration into a > Vagrant [1] box this week. This was something that was being > discussed on the DevCloud thread [2], but I wanted to break it out > into a different discussion. I've realized that I hit a bit of a road > block, and want to get the opinion of others in the community about > how far I should go to get around it. > > My intent was to break up the DevCloud creation process into two > phases. Phase 1 could be done centrally, with the resulting image > being updated on semi-regular basis. It would consist of an > unattended Ubuntu 12.04 installation (following the configuration > guidance that Edison already provided), plus install and config > xen/xcp/network (basically executing "devcloudsetup.sh -p"). Phase 1 > isn't going to be a problem really, and has nothing to do with > Vagrant. > > My issue is in getting to the second phase, for which I was intending > to do the code checkout, build and final configuration steps within > the VM. > > A little bit of background on Vagrant might help those that haven't > used it before: > > It's basically an elegant (IMO) way to encapsulate a set of > configuration and provisioning steps for a VM (or multiple VMs) within > VirtualBox. It's very much designed with developers in mind. Edison > has already provided a fully configured OVA, but the benefit we would > have of using something like this would be to ensure that everyone > using the Vagrant process would be able to consistently build and > teardown DevCloud instances with the most up to date code (or code > from an appropriate branch). > > Vagrant has 2 functions really: VM control and "provisioning" logic. > The former simply manages the VM's hardware configuration and state > (registered, unregistered, running, sleeping, etc...). The later is > intended to provision a developer's application and config into the VM > during a "vagrant up" call (i.e.: whenever the VM is newly started). > To accomplish this provisioning process, there are 3 different > "provisioner" plugins: puppet, chef and ssh. For these to work, the > guest OS needs to have the VirtualBox Guest Additions installed and > functioning... specifically, they make heavy use of VirtualBox shared > folders to push artifacts into the VM. They also use ssh to interact > with the guest OS, but it has the expectation that the shared folder > is available to stage temporary script files for each individual > command being sent. > > The problem that I've hit is that the VirtualBox guest additions > kernel module is rendered non-functional when the VM is booted into > dom0. I'm frankly not enough of a kernel guy to figure out if there > is a hack to make it work. If someone else wants to give it a shot, > I'd be more than happy to walk through the steps to reproduce the > issue. > > As far as I can tell though, the option that I have to make Vagrant > work is to get in contact with the maintainers of that project and > discuss options for an alternate "provisioner" plugin (or how to use > what's there in a different way). > > I'm looking for comments on two questions: > 1 - Does the community (besides myself) have a significant enough > interest in using Vagrant to make it worth the time to sort out the > provisioner issue?
Are you installing the -headers -devel kernel packages for the Xen kernel (I have no idea of Ubuntu/debian call the packages -headers/-kernel - it could be that it's not not able to build the new packages. So the only other immediate idea is this: Divide this up into runstages - 1 for the prep - and then when everything is configured - change the kernel you boot too as the final runstage, after which it should be ok that the vagrant plugin doesn't load. > > 2 - Does anyone have an alternate suggestion for how to achieve what I > had hoped to achieve? libguestfs? It certainly won't do everything, but might do some of it.
