cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <>
Subject Update on wrapping DevCloud into a Vagrant Box
Date Thu, 12 Jul 2012 20:32:32 GMT
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 " -p").  Phase 1
isn't going to be a problem really, and has nothing to do with

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

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,



View raw message