Mobile web/MobileFrontend deployment

= Schedule =


 * Finish backlog tasks
 * Trial Deployment
 * Production ramp up

= Current Requirements for Trial Deployment =

WURFL support in MW Memcache interface
Converting from using the php memcache extension to the built-in mediawiki memcache interface for the WURFL php api. Starting development on this task tomorrow.
 * Need to update php wurfl api to use mediawiki's memcache interface -- Blocker

Squid mobile redirector

 * Squid mobile redirector - the squid config (acl's for mobile device and opt-out cookie detection) is finalized and tested with the redirect logic implemented in perl. The perl needs to be ported to C and ensured to be fast, ram efficient, and leak free. Simple but due to risk involved in impacting nearly all wikipedia requests, may need a full day or more of testing.

Trial Rollout

 * How do we want a trial version of the new mobile site to be accessed? x% of requests to the current mobile vip, or new vips with test names (i.e. en.newm.wikipedia.org)


 * If we want host names to stay the same and run a cookie based trial (i.e. users transparently get the new site when going to en.m.wikipedia.org if I have the test cookie set) :
 * We need a proxy sitting in front of the ruby mobile servers (such as nginx or haproxy) on port 80
 * Reconfigure ruby apaches to port 81
 * Proxy configured with two backend pools - one is just localhost:81, the other is the individual new-mobile varnish hosts
 * Dispatch based on cookie
 * This isn't complex but if the new mobile varnish cluster is in eqiad, it might add up to 120ms of latency from multiple back and forth hops across colos


 * New vip - what do we name the base? *.nm.wikipedia.org?
 * LVS config for the new vip and varnish hosts behind it (need Ryan's help)
 * DNS for test versions of all wikipedia sites
 * Deploy the new mobile redirect logic to the squids, with the C redirector modified to use the test domain name
 * Add a squid acl to only invoke the redirector if the cookie is set (this should be possible but need to verify)


 * In either case, need to update mobile vcl to rewrite chosen hostnames back to $lang.wikipedia.org to be supported transparently by apache / mediawiki.

Mobile Varnish cluster

 * Mobile Varnish cluster - waiting to hear from Mark if we can piggyback on and expand the bits cluster
 * If Yes: Need to reconfigure varnish to use all available ram, likely need to put nginx in front, mobile vcl needs to be updated to play nicely with the current version (don't execute at all for bits requests)
 * If No (this might actually be better): we can use the 5 mobile servers ordered in Ashburn for Varnish (may need RobH to complete server builds)
 * Need nginx with consistent uri hashing - that module probably needs to be built from source and packaged into a dpkg for deployment
 * Puppet rules to build mobile cache servers (nginx w/hash module on 80 and varnish on 81 with/mobile vcl)
 * Nagios monitoring for varnish on a non-standard port?

Varnish multicast cache purge support

 * Varnish multicast cache purge support - requires running a daemon written by wikia on each host
 * https://svn.wikia-code.com/utils/varnishhtcpd/htcpd-stomp-inject
 * Needs to be installed via puppet with a startup script / config piece written
 * Is network configuration needed to get multicast purge messages to varnish hosts? Most likely if using servers in Ashburn. Needs Mark

Varnish udp2log patch

 * Logging - we still need Varnish log2udp support via a logging daemon
 * What would be a good TTL setting for multicast? (Right now I defaulted to 1 second which is the same as it is in squid.)
 * Implemented and is in testing by Patrick. Tfinc 19:17, 7 July 2011 (UTC)

Install Mobile frontend in production

 * Install of mobile extension to production mediawiki cluster - this needs to be done as part of the mediawiki app install process
 * Need help of someone familiar with deploying new mediawiki extensions to prod
 * Patrick can own this since he has deployment experience Tfinc 19:17, 7 July 2011 (UTC)