User:MHolloway (WMF)/Draft:Mobileapps Notes for Ops

The mobileapps service (a.k.a. "mobile content service") provides a facade through which Wikimedia content is requested, modified to remove unnecessary bits and put into a form most readily consumable by the mobile apps, and sent on to the client. The underlying content is primarily Parsoid HTML fetched via a request to RESTBase, in which responses are cached for future use. As of February 2016, the service is consumed by all users of the Wikipedia Beta app for Android.

You can read about the service in detail here.

Where it runs

The mobileapps service runs on Service Cluster B (scb1001 and scb1002). Requests from the apps are directed to the service via {protocol}://{domain}/api/rest_v1/....

Rollout plans and procedures

The service was rolled out to increasing percentages of Android Beta app users from December 2015 through January 2016. It is currently consumed by all users of the app (with the exception of requests to zh.wikipedia.org, which are still sent to the MediaWiki action API due to internationalization concerns). Plans to roll out the service to the production Wikipedia app for Android are pending.

Gradual rollouts are managed via a configuration setting in the MobileApps extension, as reflected here (see restbaseBetaPercent). Changes are made in the extension, then backported during a SWAT window to the branch currently deployed on Wikimedia wikis (and any subsequent release branches prior to the current development branch).

After backporting, a cache purge has been necessary for the change to take effect.

On deployment.eqiad.wmnet:
echo "https://www.wikimedia.org/static/current/extensions/MobileApp/config/android.json" | mwscript purgeList.php --wiki=aawiki

Note: The cache purge instruction must be run against www rather than meta, since the file lives under /static/, which gets normalized to www.wikimedia.org in Varnish.

Consequences of shutdown/failure

The Android app has a fallback mechanism in which it will temporarily revert to old-style action API content requests after a "significant" failure (a page load error other than a 404 or client-side networking error). After falling back to the MediaWiki API, the app will wait for 100 successful requests and then again attempt a request from the mobile content service, falling back again in case of error.

After the first failed request to the content service, the app should behave identically to the end user after falling back to the MediaWiki action API. The only exception is Wiktionary definition functionality, which requires the mobile content service (and will not appear to the user in the relevant context menu if content service loading is unavailable).