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? 2 - Does anyone have an alternate suggestion for how to achieve what I had hoped to achieve? Thanks all, -chip [1] http://vagrantup.com/ [2] http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-dev/201207.mbox/%3CCA%2B96GG6Y19zjFtdeOZg1nXJV_Q0_qX77v3cjwRQ%2BABU%3D-rYyBg%40mail.gmail.com%3E
