I did a session at ApacheCon on using Vagrant to manage a dev VM for open source projects. I suggest that it is best to start from a plain vanilla Linux distro and provision the VM from initial setup. This makes it easier for the community to maintain (just scripts).
I recently published a screencast based on the presentation. This uses shell scripting for provisioning but it would be better to use Chef or Puppet (or other) to provide more potential for reuse in final deployment. Thought I'd share here for feedback since you already do some of this. See http://msopentech.com/blog/2014/04/23/using-virtual-machine-images-community-development-open-source-project/ If the team here are interested I'd be happy to help to this (actually I tried to use Allura as the demo but failed to get it working, happy to try again now I font have an imminent deadline). On 3 Apr 2014 13:36, "Dave Brondsema" <[email protected]> wrote: > > https://forge-allura.apache.org/p/allura/wiki/Install%20and%20Run%20Allura%20-%20Vagrant/ > is now updated with a new vagrant box URL. (No changes to how it works) > > > On 4/3/14 2:43 PM, Dave Brondsema wrote: > > Yeah, we can put a script inside the image (e.g. like ~/start_allura). I like > > that idea. > > > > I think for today I'll just keep everything as-is though. Maybe during PyCon > > sprints I'll work on a script. > > > > On 4/3/14 10:42 AM, Cory Johns wrote: > >> Ugh. Of course update.sh won't be there if the repo is missing, but I > >> meant having some sort of script in the VM image that handles checking out > >> the repo and running the setup steps (including update.sh). Alternatively, > >> could be a wrapper script that handles cloning the repo and initializing > >> the VM (similar to ievms). > >> > >> > >> On Thu, Apr 3, 2014 at 10:15 AM, Cory Johns <[email protected]> wrote: > >> > >>> +1 for shared folder, as well, but could we possibly make update.sh handle > >>> the git clone from the vagrant side if the code is missing? > >>> > >>> > >>> On Thu, Apr 3, 2014 at 6:41 AM, Wayne Witzel III <[email protected] >wrote: > >>> > >>>> +1 shared folder. Like Tim said, it is what people who are used to > >>>> developing with Vagrant expect. FWIW I've also never felt the shared > >>>> folders in Vagrant were slow. > >>>> > >>>> > >>>> On Thu, Apr 3, 2014 at 1:31 AM, Igor Bondarenko <[email protected]> > >>>> wrote: > >>>> > >>>>> +1 for leaving shared folder setup as is > >>>>> > >>>>> > >>>>> On Thu, Apr 3, 2014 at 7:12 AM, Tim Van Steenburgh < > >>>>> [email protected] > >>>>>> wrote: > >>>>> > >>>>>> FWIW, I would leave the shared folder setup as-is. I use this vagrant > >>>>>> setup regularly for other projects and I've never noticed a > >>>> performance > >>>>>> penalty - it's always felt as responsive as accessing local files. I > >>>>> would > >>>>>> think people kind of expect this setup when using vagrant (if they've > >>>>> used > >>>>>> it before anyway). And if we change it, we'll only end up replacing > >>>> the > >>>>>> `git clone` instructions with nfs mount or rsync instructions. > >>>>>> > >>>>>> > >>>>>> On Wednesday, April 2, 2014 at 6:40 PM, Dave Brondsema wrote: > >>>>>> > >>>>>>> I'm working on building a new vagrant image, since the last image we > >>>>>> built was > >>>>>>> back in August. Our instructions [1] specify doing a git clone of > >>>> the > >>>>>> repo (and > >>>>>>> I actually missed that and got tripped up by lack of source!). But > >>>>> would > >>>>>> it > >>>>>>> make more sense to include the git repo within the machine image? > >>>>> That'd > >>>>>> make > >>>>>>> it easier to get up and running (especially if you don't have git > >>>>>> installed on > >>>>>>> the host). Code getting stale wouldn't be an issue since our Vagrant > >>>>>>> instructions specify to run update.sh (http://update.sh) which > >>>>> includes > >>>>>> a git pull. > >>>>>>> > >>>>>>> The downside is that the allura source wouldn't be in a shared > >>>> vagrant > >>>>>> folder > >>>>>>> for easy access with your favorite editor, it'd have to be edited > >>>> with > >>>>>> vim > >>>>>>> inside the vagrant box. But shared vagrant folders are pretty slow > >>>>>> anyway, so > >>>>>>> its probably better to recommend development via a different shared > >>>>>> method > >>>>>>> (vagrant supports NFS or rsync now). See speed comparison at [2]. > >>>>>>> > >>>>>>> A different option would be to recommend downloading an official > >>>>> release > >>>>>> instead > >>>>>>> of git clone. > >>>>>>> > >>>>>>> Yes? No? > >>>>>>> > >>>>>>> [1] > >>>>>>> > >>>>>> > >>>>> > >>>> https://forge-allura.apache.org/p/allura/wiki/Install%20and%20Run%20Allura%20-%20Vagrant/ > >>>>>>> [2] > >>>>>> > >>>>> > >>>> http://mitchellh.com/comparing-filesystem-performance-in-virtual-machines > >>>>>>> > >>>>>>> -- > >>>>>>> Dave Brondsema : [email protected] (mailto:[email protected]) > >>>>>>> http://www.brondsema.net : personal > >>>>>>> http://www.splike.com : programming > >>>>>>> <>< > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>> > >>> > >> > > > > > > > > > > -- > Dave Brondsema : [email protected] > http://www.brondsema.net : personal > http://www.splike.com : programming > <>< On 3 Apr 2014 13:36, "Dave Brondsema" <[email protected]> wrote: > > https://forge-allura.apache.org/p/allura/wiki/Install%20and%20Run%20Allura%20-%20Vagrant/ > is now updated with a new vagrant box URL. (No changes to how it works) > > > On 4/3/14 2:43 PM, Dave Brondsema wrote: > > Yeah, we can put a script inside the image (e.g. like ~/start_allura). > I like > > that idea. > > > > I think for today I'll just keep everything as-is though. Maybe during > PyCon > > sprints I'll work on a script. > > > > On 4/3/14 10:42 AM, Cory Johns wrote: > >> Ugh. Of course update.sh won't be there if the repo is missing, but I > >> meant having some sort of script in the VM image that handles checking > out > >> the repo and running the setup steps (including update.sh). > Alternatively, > >> could be a wrapper script that handles cloning the repo and initializing > >> the VM (similar to ievms). > >> > >> > >> On Thu, Apr 3, 2014 at 10:15 AM, Cory Johns <[email protected]> wrote: > >> > >>> +1 for shared folder, as well, but could we possibly make update.sh > handle > >>> the git clone from the vagrant side if the code is missing? > >>> > >>> > >>> On Thu, Apr 3, 2014 at 6:41 AM, Wayne Witzel III <[email protected] > >wrote: > >>> > >>>> +1 shared folder. Like Tim said, it is what people who are used to > >>>> developing with Vagrant expect. FWIW I've also never felt the shared > >>>> folders in Vagrant were slow. > >>>> > >>>> > >>>> On Thu, Apr 3, 2014 at 1:31 AM, Igor Bondarenko <[email protected]> > >>>> wrote: > >>>> > >>>>> +1 for leaving shared folder setup as is > >>>>> > >>>>> > >>>>> On Thu, Apr 3, 2014 at 7:12 AM, Tim Van Steenburgh < > >>>>> [email protected] > >>>>>> wrote: > >>>>> > >>>>>> FWIW, I would leave the shared folder setup as-is. I use this > vagrant > >>>>>> setup regularly for other projects and I've never noticed a > >>>> performance > >>>>>> penalty - it's always felt as responsive as accessing local files. I > >>>>> would > >>>>>> think people kind of expect this setup when using vagrant (if > they've > >>>>> used > >>>>>> it before anyway). And if we change it, we'll only end up replacing > >>>> the > >>>>>> `git clone` instructions with nfs mount or rsync instructions. > >>>>>> > >>>>>> > >>>>>> On Wednesday, April 2, 2014 at 6:40 PM, Dave Brondsema wrote: > >>>>>> > >>>>>>> I'm working on building a new vagrant image, since the last image > we > >>>>>> built was > >>>>>>> back in August. Our instructions [1] specify doing a git clone of > >>>> the > >>>>>> repo (and > >>>>>>> I actually missed that and got tripped up by lack of source!). But > >>>>> would > >>>>>> it > >>>>>>> make more sense to include the git repo within the machine image? > >>>>> That'd > >>>>>> make > >>>>>>> it easier to get up and running (especially if you don't have git > >>>>>> installed on > >>>>>>> the host). Code getting stale wouldn't be an issue since our > Vagrant > >>>>>>> instructions specify to run update.sh (http://update.sh) which > >>>>> includes > >>>>>> a git pull. > >>>>>>> > >>>>>>> The downside is that the allura source wouldn't be in a shared > >>>> vagrant > >>>>>> folder > >>>>>>> for easy access with your favorite editor, it'd have to be edited > >>>> with > >>>>>> vim > >>>>>>> inside the vagrant box. But shared vagrant folders are pretty slow > >>>>>> anyway, so > >>>>>>> its probably better to recommend development via a different shared > >>>>>> method > >>>>>>> (vagrant supports NFS or rsync now). See speed comparison at [2]. > >>>>>>> > >>>>>>> A different option would be to recommend downloading an official > >>>>> release > >>>>>> instead > >>>>>>> of git clone. > >>>>>>> > >>>>>>> Yes? No? > >>>>>>> > >>>>>>> [1] > >>>>>>> > >>>>>> > >>>>> > >>>> > https://forge-allura.apache.org/p/allura/wiki/Install%20and%20Run%20Allura%20-%20Vagrant/ > >>>>>>> [2] > >>>>>> > >>>>> > >>>> > http://mitchellh.com/comparing-filesystem-performance-in-virtual-machines > >>>>>>> > >>>>>>> -- > >>>>>>> Dave Brondsema : [email protected] (mailto:[email protected]) > >>>>>>> http://www.brondsema.net : personal > >>>>>>> http://www.splike.com : programming > >>>>>>> <>< > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>> > >>> > >> > > > > > > > > > > -- > Dave Brondsema : [email protected] > http://www.brondsema.net : personal > http://www.splike.com : programming > <>< >
