Webdev:DevBoxVMImages

As part of bug 688911 and bug 688923, we should work on providing downloadable virtual machine images that contain ready-to-run installations of our websites. That way, a new contributor can focus on contributing, rather than learning how to install and configure a website first.

Open questions

TBD: Should this be in an etherpad?

Image generation by hand or by machine?

• Starting by hand early to iron out process
  • Need to remember to update images on a regular basis
• Switch to Jenkins or something else for nightly builds
  • How would this work? Seems resource intensive
  • See also: bug 670471 - [tracker] set up jenkins job to export socorro vagrant VM

Vagrantfile as part of project, or separate repo?

• MDN includes Vagrantfile in the main project.
  • https://github.com/mozilla/kuma/blob/master/Vagrantfile
• Socorro has a separate socorro-vagrant project.
  • https://github.com/rhelmer/socorro-vagrant
• Probably only matters to the person or process generating the VM image
  • Since we should take care of that rather than demanding contributor to do a full vagrant up

Code on host or in VM?

• Vagrant wants to wrap a VM around a directory of source on the Host.
  • Can use familiar tools, etc
  • Shared folders from VBox to Host are slow; NFS is faster but not available to Windows.
• Better if the source for the project were git clone'ed inside the VM and shipped along with the image?
  • No more shared folder from host to VM.
  • Would need to install Samba inside VM to edit code from host.
    • That's one of the major benefits of Vagrant
  • Need to configure and use git or svn inside VM
    • Might be a bummer, might help contributors have a consistent revision control scenario
    • eg. ~/.gitconfig with contributor's name and email, etc
  • Need instructions advising a git pull after initial boot-up

Blank slate content

• Need to import / generate some sample data / content to make the site useful
• Anonymized export from prod?
  • Pretty dangerous, can expose PII, should be vetted by security team
• Randomized data
  • Need to be sure it's not entirely non-sensical
• Synthetic test data
  • Need to hand-maintain

Local hardware vs Rackspace VM?

• Running a VM image oneself needs a capable machine
  • Might not be an option for a MacBook Air or netbook owner
• Running a VM on Rackspace costs $$$
  • How to get an image loaded into a Rackspace VM?

Participating sites

• AMO?
• SUMO?
• Socorro
• Mozillians?
• MDN?
  • Need proper hosting
  • http://people.mozilla.org/~lorchard/kuma-master.box
  • http://people.mozilla.org/~lorchard/kuma-mdn-with-import.box
• TBPL
• AUS
• Graphserver

Maintaining VM images

TBD: Need to flesh out a process for most sites that an experienced webdev (eg. project lead or senior dev) follow by hand and/or automate in something like Jenkins.

It might look something like this:

• Use vagrant destroy && vagrant up to spin up a VM in VirtualBox
• Build Puppet manifests to install packages and configure the VM with a running site
  • If set up by hand, then it will always need to be done by hand.
  • If automated by Puppet manifests or other scripts, then it can be run by machine
  • Do whatever is expedient, since the VM images are the important thing
  • Someday, it might be nice to steal whatever Puppet manifests IT uses, though.
• Use vagrant package to extract a {sitename}.box image, once the site is verified to be running.
• Upload the exported {sitename}.box image to hosting site for download.

Hosting VM images

TBD: bug 688923 needs some IT collaboration to acquire hosting infra for 2-20GB VM images.

people.mozilla.org is not a good place to do this, going forward

Using VM images

TBD: What are the instructions we give contributors for using a webdev VM image?

Hints, tips, HOWTOs

TBD: Collect info and gotchas on setting up sites in VMs.