Per Ops feedback on T356, it seems this is no longer needed and/or being handled routinely by other means now.
@cscott MediaWiki now supports deferring the thumbnail/image scaling effort to a separate service (as of rMWa9213ccb4c77: Add ability to proxy thumbnail requests to a service). Although even before this, one could set up rewrites to bypass MediaWiki entirely for thumbnail urls.
Blocked per comments on https://gerrit.wikimedia.org/r/#/c/392542/, on:
- Remove use from tarball-bundled and WMF-maintained extensions.
- Wait until the next release cycle (MediaWiki 1.32).
Withdrawn per T356.
I've narrowed the task to the WFM sysadmin request appropriate for Wikimedia-Site-requests. Per the description of Wikimedia-General-or-Unknown, the task of a global sysop performing on-wiki changes is outside the scope for any Phabricator task (unless the task is e.g. executed by Community-Tech in which case Community-Tech-fixes could be used).
For the record, yes: Renaming article_ to page_ should also be done. Thanks for spotting that.
Also, reminds me, we need to make sure that the parameters for kafka_brokers and statsd destination are injected through Puppet in such a way that automatically notifies/restarts the service when they change. As far as I know, Puppet doesn't track Hiera variables over time, so there's no detection there, but as long as they're written to disk somewhere, change detection (notify) should work. Given we invoke the service via systemd unit files, I'd assume this all just works as intended, but would be good to verify at least once after we've got both servers up and running (maybe by making a no-op change to the kafka_brokers list at some point).
@aaron What is the impact currently on this Memcached error happening during a web request? Is there a fallback? Do we show a stale sidebar? Empty sidebar? Complete error page?
Ran into two problems:
- It changed the order of stylesheets, making it FIFO instead of based on dependency tree. This broke cascading expectations (makes sense, solvable problem).
- Modules that result in failure can no longer propagate their error in a preventive manner, because the depending module's styles were already inserted and shown to the user.
Closing for now in favour more recent and more specific tasks about memcached/nutcracker issues in wmf-production.
There have been various conversations about this on IRC and Gerrit but just writing back here for the record:
Wed, Feb 21
@demon As far as I know, individual maintenance scripts (even if run via foreachwiki) already take care of wait-for-replag, and in case of major writes, they typically also have a configurable sleep cycle, which can be passed down from foreachwiki. Is this not working well and/or what are you looking for specifically?
@Anomie Can we adapt the test to not absorb this global state? E.g. by mocking or disabling those debug logs for the purpose of this unit test?
Tue, Feb 20
I thought this was about a distinction between "errors" and "warnings". The CheckStyle report talks about "0 warnings" where the console output includes <error> tags. However, it seems unlikely that "errors" would be considered less important than "warnings".
Closing in favour of T146285. Any hosts on which mwscript is meant to be used (maintenance hosts, deployment hosts, dump hosts) have php5 packages enabled so that things like Memcached works. If there are any other uses of php5 in production that interact with MediaWiki and are missing these packages, they would break very early on with a fatal for undefined class. There is no further action item for this task, other than: Remember to install php5 packages before using php5 on a server - which we have now done all all known cases.
@Samwilson I'd recommend tracking that as a separate task because it involves explicitly changing the format of a preference key, and none of the array-like use cases you mentioned are subject to normalisation inconsistencies.
@Peter At least one thing to address is that we currently have a logic mismatch between adding a link to the sidebar (onBaseTemplateToolbox) and loading the modules which add the click handler (onBeforePageDisplay). In one we only check the user preference, in the other we also check the page title namespace. We should use the same logic in both.
Mon, Feb 19
The only difference between the two implementations of dev settings are these lines, which were added to DevelopmentSettings.php after the initial import from integration/jenkins.git
So, given Python isn't super easy to instrument it seems (no support for creating a perf-map). Let's keep looking for another relatively simple service to instrument. Perhaps one of the Node.js services. Or maybe even on MediaWiki itself using HHVM on a subset of servers (e.g. mwdebug, or the canary servers).
Per @Imarlier, seems Python doesn't have a good production-level (sampled) profiling story right now. If really needed, we could make this work for a different Python service, but the purpose of this task was to do it for a simple service first, to validate the bootstrapping work of T185234. Given navtiming won't be the "simple and perf-compatible service" we were looking for, closing this in favour of a to-be-determined other service to instrument.