> -----Original Message----- > From: Chip Childers [mailto:chip.child...@sungard.com] > Sent: Thursday, July 12, 2012 1:33 PM > To: cloudstack-dev@incubator.apache.org > Subject: Update on wrapping DevCloud into a Vagrant Box > > 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?
If it can work without VirtualBox Addon(ssh/scp works, why the shared folder is a must?), then we will use it. It's not worth to spend a lot of time on getting Addon work in dom0, Addon is not intended to work in dom0. > > 2 - Does anyone have an alternate suggestion for how to achieve what I > had hoped to achieve? If automate doesn't work, document it?,.. > > 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
