Mobile web/MobileFrontend deployment

= Schedule =

Launch Sprint
Goal: Sprint Planning for deploying the Mobile frontend

Stories

What do we have to do in order to dark launch and have an opt in system for mobile? .. and then Production launch two week later


 * Install Varnish on tesla - high
 * Test Patricks new varnish code - high
 * Profile user agent detection - Will we need to expand the Bits Varnish cluster?
 * base64 encode images - http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/libs/CSSMin.php?view=markup - low
 * Can we invalidate articles in varnish - will a single purge cover all possible variants of a document? - high
 * Where is the extension going to run?
 * Do we need to order hardware for this? - high
 * Add profiling for extension - high
 * Do we need to use .m urls? YES .. how can we do it? - high
 * Squid redirect patch
 * Don't redirect people who have opted out
 * Write udp log patch for Varnish using the same logformat - see: https://rt.wikimedia.org/Ticket/Display.html?id=85 - med
 * Can add an new column in the log to surface render type (wap vs smartphone)

External testing sites:
 * http://www.blaze.io/mobile/result/?testid=110617_4M_394

Current Requirements for Trial Deployment

 * Need to update php wurfl api to use mediawiki's memcache interface -- Blocker
 * 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.
 * 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)
 * In either case, need to update mobile vcl to rewrite chosen hostnames back to $lang.wikipedia.org to be supported transparently by apache / mediawiki.
 * New vips+names require assistance from Ryan as that's new to me (may require several days of scheduling or training overhead)
 * 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 - 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
 * Logging - we still need Varnish log2udp support via a logging daemon
 * 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