On Mon, Oct 15, 2012 at 10:28 PM, Andrew Bogott <abogott(a)wikimedia.org> wrote:
Does a single-instance install provide a sufficient
test platform for 80% of
the likely patches, or does all of the interesting stuff require a
full-blown cluster?
Define "sufficient" :). Most development is done on "single instance"
configs (developer machines) with varying degrees of sophistication
before it hits the cluster. The environment defined in
labsmediawiki.pp is very simplistic indeed, but I'd venture a guess
that some devs (both inside and outside WMF) develop even with
similarly minimal developments _right now_; maybe we can do some
informal experience sharing on that at the Thursday tech chat to see
just how far most local dev environments deviate from production, how
many folks run what types of tests, etc.
A dev-environment-in-a-box is emphatically not a replacement for a
staging cluster like Beta Labs. What you'd do is:
1) Develop locally against VM environment, run tests in VM, rinse, repeat
2) Submit changeset for review; upon test pass and review, change gets
merged auto-deployed to Labs
3) Deploy changeset into prod
We already have 2) in a working state, and 3) is a hybrid of scheduled
deployment windows + some ad hoc deployment right now. But we don't
have 1) at all, so we basically tell every new dev to make up their
dev environment from whole cloth, meaning that after 1) is when the
nasty surprises happen.
I think there's a lot that can be done with a single instance setup to
ease that pain. To take the Kuma example, the VM not only comes with
the core software, but also with fun dependencies like NodeJS,
RabbitMQ, Sphinx Search, etc. all configured to work correctly, as
well as the whole test suite runnable right away. The equivalent for
us would be to have stuff like Lucene search, the full unit test
suite, or a Parsoid NodeJS service running "out of the box" -- not to
mention nice debug settings by default.
If single-system servers are truly useful in most
cases, then a prepackaged
VM image seems straightforward and handy. Presuming that the devs are
willing/able to run a few git commands before they start coding, we could
potentially leave puppet and Vagrant out of the equation and just build a
one-off image by hand and include strict instructions to fetch and rebase
immediately after opening.
A Kuma-style Vagrant config lets you develop on the host machine
(using your favorite IDE, dev tools, etc.) with the dev dir mounted
via NFS and accessible in the VM. Vagrant makes that pretty painless.
So you can do:
me@mylaptop:/var/www/mediawiki$ git commit -m 'Awesome stuff' -a
on your host machine, while you're logged in via
me@mylaptop:/var/www/mediawiki$ vagrant ssh
to your guest VM to administer/restart/configure services. I've found
this pretty performant on a mid-level PC, although obviously there's a
penalty for using a VM.
The Vagrant folks say using NFS exports is the best way to overcome
massive performance issues with VirtualBox shared folders when dealing
with larger numbers of files:
http://vagrantup.com/v1/docs/nfs.html
I tested this in practice and indeed, without NFS, the Kuma VM was
pretty much unusable. Again, Vagrant eliminates the need to wrestle
with these details as a dev end user -- as long as you have NFS
installed and enabled in the Vagrant config, it'll take care of it for
you.
It looks like that's roughly what Mozilla is
doing at the moment.
The Kuma VM comes with detailed Puppet manifests:
https://github.com/mozilla/kuma/tree/master/puppet/manifests
Whenever you run "vagrant up" to start the VM, it runs the
provisioners set up in the Vagrantfile. This means that if the PP
files change in the repo, as a dev end user, you'll more or less
automatically get updated service definitions.
The VM image you can download already has most of the required stuff
pre-installed to speed things up, but for example, RabbitMQ was
installed after-the-fact via Puppet.
Vagrant shields developer end users from most of the details of Puppet
in practice, while providing its benefits by making it relatively
straightforward to stay up to date with whatever the recommended
"standard dev environment" is without downloading new box images (and
thereby losing whatever local customizations you've made).
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge:
https://wikimediafoundation.org/wiki/Donate