It is possible to import a box using 'vagrant box add', which takes a box name argument and a URL or file path. The box name should match the one specified in the Vagrantfile - namely, 'precise-cloud'.

Examples:
$ vagrant box add precise-cloud /path/to/file/precise.box
$ vagrant box add precise-cloud http://someurl.org/precise.box

[mass-moving from Tools>MediaWiki-Vagrant to separate product. See bug 54041. Filter bugmail on this comment.]

We could make platform specific packages for this that are completely self contained - dmgs for OS X, debs/rpm (with all data) for Linux, and whatever it is that Windows does.

We had a meeting about building a more production-like Vagrant setup. One of the subtopics was how to make it easier to distribute and setup Vagrant to help get new contributors at hackathons and such.

A few ideas were:

• (Bryan Davis) Have a network server to distribute all the installers
• Distribute USB drives so people don't need to use the network at all.
• LiveCD for running Vagrant (but people don't want to use a LiveCD long-term, so this doesn't solve the problem of integrating it into your normal daily workflow)

I think we should consider the following:

1. Write script to build some kind of directory of MWV-related files. This could include:
2. VirtualBox for various platforms
3. Vagrant for various platforms
4. Ubuntu base box
5. More sophisticated (suggested by Yuvi): install script or package (e.g. DMG) that sets up more than one package at a time.

2. Building a LiveCD or LiveDVD (and script for generating it) that can just be booted to launch a network server (NFS and/or SMB) distributing the MWV-related files. This can be shared on a LAN to save people using scarce Internet.

3. Building a USB drive with the MWV-related files.

I'm going to make a bug for #1. If people agree both #2 and #3 are worth doing, I'll make bugs for those as well. The alternative is to pick just #2 *or* #3 to focus on for now.

With #2 or #3, the same directory should be usable in both cases.

Another question is whether to put the build scripts in the main Vagrant repo, or set up a new one.

A packaged directory (a la bug 60982) that we can pre-copy onto a bunch of USB sticks sounds ideal to me. Even local wifi can end up borking too easily in a hackathon setting to rely on LAN distribution.

Alright, I've made and assigned to myself bug 61060 for that in general (linking to the one specific to DMGs).

Hm, hackathon is approaching quickly, is this considered important for its success or just a nice to have?

Based on my latest personal experience with MWV (https://www.mediawiki.org/?diff=912744&oldid=889141), I wonder if network and file fetch is really the bottleneck or once we solve it we'll find worse problems, like the 2 hours required for the initial puppet run in the first "vagrant up".

Perhaps it's easier to use remote virtual servers instead? They have better network, usually better CPU, and most importantly can even be set up in advance. Then the hackers only have to learn keys and ssh (which they have anyway) and they can still use their local text editors and whatever via their [[KIOslaves]] or equivalent if that's a problem. Labs already allows making instances with vagrant roles, though I've not tried before, and another option is AWS which also has a free trial (very hard to run into its limits with a test wiki). Anyone liking the latter option, please add bug 58896 to blockers of this bug.

(In reply to Nemo from comment #7)

Hm, hackathon is approaching quickly, is this considered important for its
success or just a nice to have?

Yes, it's important, and I will definitely be doing bug 61060 before the Zürich Hackathon.

Based on my latest personal experience with MWV
(https://www.mediawiki.org/?diff=912744&oldid=889141), I wonder if network
and file fetch is really the bottleneck or once we solve it we'll find worse
problems, like the 2 hours required for the initial puppet run in the first
"vagrant up".

Yes, most of the time is used in downloading. For instance, generally most of the Puppet time is used for downloading the entire MediaWiki core git repository (with all history). That is one of the files I will be bundling with bug 61060.

Perhaps it's easier to use remote virtual servers instead? They have better
network, usually better CPU, and most importantly can even be set up in
advance. Then the hackers only have to learn keys and ssh (which they have
anyway) and they can still use their local text editors and whatever via
their [[KIOslaves]] or equivalent if that's a problem.

This is worth investigating/trying, but I won't be looking at it before Zürich.

The Hackathon is next week. Do we have a plan?

otto wrote:

https://gerrit.wikimedia.org/r/#/c/130572/

(In reply to Andrew Otto from comment #10)

https://gerrit.wikimedia.org/r/#/c/130572/

To expand on Andrew's comment, for the Zürich Hackathon we will be making USB thumbdrives with key install files for setting up MediaWiki-Vagrant. Matt's patch should make repeating this process in the future easier.

Quim, the script for bug 61060 is merged. Ori has USB drives. He is in the process of generating an ISO file containing all the resources mentioned in that bug. He will then ask WMF IT to burn/copy the image onto USB drives, and bring the USB drives to Zürich.

This tracking bug will remain for now, since there is broader scope possible (e.g. making one-click installers that install all dependencies, do the clones from the bundles, etc.).

USB drives were used to great success at the MediaWiki-Vagrant bootcamp session given at the Zürich hackathon. One nice idea for the future would be to add a pre-populated apt-cache and/or a custom base image that has been taken from a clean base VM after the initial puppet run.

I did the apt-cache route (bug 64928), though some improvements are probably possible (i.e. including the packages a fresh box needs on first 'provision', and maybe ones needed by very common extensions, rather than the ones that just happen to currently be in the apt-cache directory).

All blocking tasks resolved. Can this "tracking" task be closed as resolved too?