Wikimedia Labs

Wikimedia Labs is a two part project aimed at improving the volunteer involvement in operations and software development. The first part of this project is Test/Dev Labs, and the second part is Tool Labs.

As of 2 November 2011, it's in a closed beta -- if you want an account, ask Ryan Lane and if you want to use it to do MediaWiki development, tools, or analytics, he'll probably say yes and set you up.

Goals
There are three major goals of Test/Dev Labs:


 * 1) To improve collaboration between staff and volunteer developers.
 * 2) Have a process for providing higher levels of access for people who are not on the paid operations team staff. This includes staff developers, and all volunteers. We'd like to have an environment where anyone can eventually become root, even on our production cluster.
 * 3) Have an environment where we can test major changes before we deploy them to the live site.

The last point requires some background: we currently have no testing environment. Most architecture changes happen live. To bring higher uptime to the sites, it's important to have a controlled non-production environment to test changes.

Achieving these goals
We can achieve the goals by providing liberal access to an environment that is a clone of our production environment. In this environment it should be possible to add new architecture without affecting production, or the production clone. Users will be able to make root level changes without having root, and they will be able to have these changes implemented on the production cluster after favorable review. Here's how we'll go about it:


 * 1) Create a default OpenStack Compute (nova) project (testlabs)
 * 2) Build a clone of the production cluster in this project
 * 3) Move our puppet configuration into a public git repo
 * 4) * Have two branches: production, and test; the test branch will control the clone, and production will control the production cluster
 * 5) Give liberal access to this clone. Everyone that has commit access will have shell access on the clone. Anyone wanting to volunteer as an operations engineer will also have shell access. Higher level permissions will be assigned via groups.
 * 6) Create new OpenStack projects for community or foundation initiatives that change the architecture
 * 7) Project owners will be able to create instances inside of the project
 * 8) Project owners will have full root access inside of the instances, and will be able to add others into the projects, with varying levels of access.
 * 9) Users will be able to build out infrastructure inside of the project, that can then be formalized, via puppet manifests, templates, and files
 * 10) Users will be able to check out the puppet configuration from the git repo, make modifications to add their new infrastructure, and make a merge request to push them back into the test/dev infrastructure
 * 11) Once the changes have been merged into test/dev, they'll be tested
 * 12) After the changes have been tested, a merge request can be done to the production branch.
 * 13) The changes will be reviewed for production, and if approved, can then be pushed directly to production systems

This is treating operations work like a software developer project. This lets us open access to ops like we currently do with MediaWiki.

Furthermore, we'll also be providing easy access to create new wikis, using either deployment or trunk branches, with preseeded content for testing. Access to these wikis will be controlled via groups, which are also OpenStack projects.

Tool Labs
The design for Tool Labs is still in the very early phases; it may change drastically as the project ramp up begins. The first target of Tool Labs is to be a replacement for Toolserver.

Goals

 * Provide an environment for rapid prototyping
 * Close to production, but simplified
 * Easy deployment of MediaWiki
 * Provide a ramp for new developers
 * Tools and extensions can easily move to Test/Dev Labs
 * Provide a location for bot authors to maintain and run their bots
 * Provide a location for analytics work

Achieving these goals

 * 1) Create a production-like environment with the difficulties removed
 * 2) * For instance, MediaWiki instances will not have Squid/Varnish in front. It won't be broken up into multiple clusters. It will have popular development tools available upon creation. It should handle web server configuration, and MediaWiki instance creation
 * 3) * Like Toolserver, this environment will have replicated databases, and will have database servers available for users to create their own databases
 * 4) * Anonymized log data should also be provided in this environment to assist with analytics and stats work
 * 5) Accounts for both Labs environments will be the same. To move to Test/Dev Labs, one will simply need to be added to another OpenStack project

A key goal of Tool Labs is to provide an easy development environment meant to be used as a ramp to the Test/Dev Labs environment. The goal is to facilitate the rapid development of software that we can then identify as something target-able for production support. Software can be moved from Tool Labs to Test/Dev Labs, formalized, and then deployed to production.

Implementation
The architecture is described on Wikitech. The software for controlling this environment is implemented as a MediaWiki extension, and is described on mediawiki.org.

Proposals

 * Development Process
 * Shared home directories per project
 * Puppet learning mode

Roadmap

 * Move instance storage to Gluster on the compute nodes (done)
 * Provide a volume storage solution
 * Blocker for any project requiring more than 20-40GB storage
 * Gluster? iSCSI via NetApp? iSCSI to an instance that shares via Gluster in instances?
 * Fix sudo policy for non-testlabs projects (done)
 * Provide separate puppet branches per project, where that project's instances are managed by that puppet branch
 * Configure clone of production cluster
 * Configure LVS
 * Configure Squid
 * Configure Varnish
 * Configure Apache
 * Configure MySQL
 * Configure Memcached (done)
 * Configure HTTPS
 * Configure Search
 * Configure PDF
 * Write wiki creation scripts for use with multiple projects and different mediawiki versions
 * Enable database replication
 * Tungsten and MariaDB with LDAP authentication?
 * Create an all-in-one mediawiki instance based on deployment branch