I know a lot of bot creators and authors are curious about how to get
going on Wikimedia Labs. They're also curious about whether it makes
sense to put bots on Labs, and if so, how.
In early June, at the Berlin hackathon, Anomie (Brad Jorsch) talked with
Mutante (Daniel Zahn) at my request to try to figure this out. He wrote
the summary below on June 2nd, and I should have forwarded it far sooner
- my apologies for the delay (I thought it would need more editing and
clarification than I ended up doing).
This guide seems useful to me. Please do make corrections and updates,
and then we can put it up at
labsconsole.wikimedia.org for people who
want this sort of HOWTO.
A couple things I want to annotate:
* Wikimedia Labs does not have Toolserver-style database replication
right now. That is on the WMF to-do list but there is no predicted date
in the roadmap at
https://www.mediawiki.org/wiki/Wikimedia_Labs . Given
what TParis and Brad say below, that's a prerequisite to the success of
Tool Labs.
* It seems like Ops would be interested in having some bots run on the
WMF cluster, after sufficient code and design review. (I infer this from
the 5th step mentioned below and from my conversations with Daniel Zahn
and Ryan Lane.) I don't think there's currently a process for this sort
of promotion -- I suppose it would work a little like
https://www.mediawiki.org/wiki/Writing_an_extension_for_deployment .
Thanks to Brad for this summary!
best,
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
Hi Sumana,
Here is my report on the Labs discussion. It turns out that in a way we
weren't thinking big enough, or in another way we were thinking too big.
What Ops (as represented by Daniel Zahn) would prefer as far as
Wikipedia-editing bots would be one Labs project managed by someone (or
some group) who isn't Ops, and that person/group would take care of
giving people accounts within that project to run bots. I guess the
general model is vaguely along the lines of how the Toolserver is run by
WMDE and they give accounts to people. I may have found myself a major
project here. ;)
But I did also get detail on how to get yourself a project on Labs, if
you have reason to, and some clarification on how the whole thing works.
In light of the above it might not be that useful for someone wanting to
move a bot, but in general it's still useful.
Step one is to get a Labs/Gerrit account via
https://www.mediawiki.org/wiki/Developer_access .
Step two is to put together a proposal (i.e. a paragraph or two saying
what it is you plan to do) and do one of the following:
1. Go on IRC (I guess #wikimedia-labs or #wikimedia-dev or #mediawiki),
find one of the Ops people, and pitch your proposal.
2. Go on the labs-l mailing list and make your proposal.
3. File it as an "enhancement request" bug in Bugzilla.
4. Talk to an Ops person in some other way, e.g. on their talk page or
via email.
(You should probably try to get Ops as a whole to decide which of the
above they'd really prefer, or if they'd prefer using [[mw:Developer
access]] or something like it instead.) If they decide they like your
project, which Daniel says the default is currently "yes" unless they
have a reason to say "no", they'll set it up with you as an admin over
that project.
Step three then is to go log into labsconsole, and you can create a new
"instance" (virtual server) within your project. I'm told there are
various generic configurations to choose from, that vary mainly in how
much virtual RAM and disk space they have. Then you can log into your
instance and configure it however you need. I guess it will be running
Ubuntu, based on what I was told about how the Puppet configuration
works.
At this level, it is either possible or on the road map to get various
helpful services:
* Public IP addresses. [possible right now]
* Ability to have a Git repository automagically cloned, turned into a
deb package, and installed in a private Wikimedia-sepecific Ubuntu
package repository (which can then be installed from). [possible now]
* A UDP feed of recent changes, similar to the feed available over IRC
from [[meta:IRC/Channels#Recent changes]] but without having to mess
with IRC. In fact, it's the same data that is used to generate those
IRC feeds. [roadmap?]
* Access to a replicated database something like they have on the
Toolserver (i.e. no access to private data). [roadmap]
* Other stuff? I get the impression Ops is open to ideas to make Labs
more useful to people.
BTW, I mentioned Labs to TParis and the rest of the guys over here, and
they say that a replicated copy of the database like the Toolserver has
is absolutely essential before most people could move their stuff from
the Toolserver to Labs.
As far as resources go,
* Each Labs project can request one or more public IP addresses to
assign to their instances. More than one public IP needs a good
reason; maybe that will change when IPv6 is fully supported. Instances
cannot share IP addresses. But all instances (from all projects) are
on a VLAN, so it should be possible to set up one instance as a
gateway to NAT the rest of the instances. No one has bothered to
actually do this yet. Note that accessing Wikipedia requires a public
IP; there is no "back door".
* Each Labs project has a limit on the number of open files (or
something like that) at any one time. No one has ever had to change
the current default limit on this, yet.
* There is something of a limit on disk I/O, e.g., if someone has a lot
of instances all accessing terabyte-sized files all the time, that
would blow things up. This might be a global limitation on all
projects.
* I guess most other resources are limited on a per-instance basis. For
example, disk space available and RAM availble.
You *could* stop here, although Ops would really like you to continue on
to step 4.
Step four, once you've gotten your instance configuration figured out
and working, is to write a Puppet configuration that basically instructs
Puppet how to duplicate your setup from scratch. (How to do this will
probably turn out to be a whole howto on its own, once someone who has
time to write it up figures out the details.) At a high level, it
consists of stuff like which Ubuntu packages to install, which extra
files (also stored in the Puppet config in Git) to copy in, and so on.
This puppet configuration needs to get put into Git/Gerrit somewhere.
And then Ops or someone else with the ability to "+2" will have to
approve it, and then you can use it just like the generic configs back
in Step 3 to create more instances. If you need to change the
configuration, same deal with pushing the new version to Gerrit and
having someone "+2" it.
The major advantage of getting things Puppetized is that you can clone
your instance at the click of a button, and if the virtual-server
equivalent of a hard drive crash were to occur you could be up and
running on a new instance pretty much instantly. And handing
administration of the project on to someone else would be easier,
because everything would be documented instead of being a random
mish-mash that no one really knows how it is set up. It's also a
requirement for going on to production.
This is not necessarily an all-or-nothing thing. For example, the list
of packages installed and configuration file settings could be
puppetized while you still log in to update your bot code manually
instead of having that managed through Puppet. But I guess it would need
to be fully completed before you could move to production.
Step five, if you want, is to move from labs to production. The major
advantages are the possibility to get even more resources (maybe even a
dedicated server rather than a virtual one) and the possibility to get
access to private data from the MediaWiki databases. I guess at this
point all configuration changes whould have to go through updating the
Puppet configuration via Gerrit.
I don't know if you were listening when we were discussing downtime, but
it doesn't seem to be that much of a concern on Labs as long as you're
not running something that will bring all of Wikipedia to a halt if it
goes down for an hour or two. Compare this to how the Toolserver was
effectively down for almost three weeks at the end of March, and
everyone survived somehow (see [[Wikipedia:Village pump
(technical)/Archive 98#Toolserver replication lag]]).
Hope that's all clear and accurate!
Brad