TLDR:
* We'd like to drop MySQL 5.5 support for the
"lagDetectionMethod=pt-heartbeart"
option in $wgLBFactoryConf.
* If you have not configured the lagDetectionMethod option, or use MySQL
5.6+, then this does not affect you.
Hi,
If you host MediaWiki using MySQL (or MariaDB) and have a cluster of two or
more database hosts (using replication), then MediaWiki uses lag detection,
via the wikimedia/rdbms library. For example, if lag is too high, MediaWiki
tries to connect to a different replica database, or it may automatically
set the wiki in read-only mode for a few seconds until replication catches
up.
By default, MediaWiki uses the MySQL built-in "Seconds_Behind_Master"
feature to power this lag detection.
We also support use of Percona's pt-heartbeat service, which can be more
accurate, [1] and is what WMF currently uses. However, we are currently
unable to use its accuracy very well, because TIMESTAMPDIFF is not
supported in MySQL 5.5 (it was introduced in MySQL 5.6.4). [2]
In order to make pt-heartbeat more useful as a lag detection method, whilst
avoiding expensive roundtrips or runtime detection (which are not
acceptable in this hot code path), we'd either have to support three lag
detection methods, or to change the current one to require MySQL 5.6.
MySQL 5.5 reached end-of-life in Dec 2018, and there is an open proposal at
T273375 to drop support for it completely in a future version of MediaWiki.
[3] However, I'd like to propose we drop support for it now with the
pt-heartbeat feature specifically, as being opt-in and rarely used, so as
to not require additional complexity and maintenance for us in the form a
third lag detection method. Especially, as it might not be used by anyone.
If you're affected by this, then the upcoming MediaWiki 1.36 release would
require that you either set MW to use the default lag detection instead, or
upgrade to MySQL 5.6+.
Task: https://phabricator.wikimedia.org/T248481
Patch: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/657471
--
Timo Tijhof
Performance Team
Wikimedia Foundation
[1]
https://www.percona.com/blog/2014/05/02/how-to-identify-and-cure-mysql-repl…
[2] https://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-4.html
[3] https://phabricator.wikimedia.org/T273375
Hi all, I am Yasharth Dubey currently in 2nd-year undergrad studying CSE at
IIIT Dharwad, India. I have a good experience in web development. and would
like to contribute and look forward to participating for GSOC 2021 opting
for this org.
I am very much interested in
Upgrade WebdriverIO to the latest version for all repositories
this project and I am looking forward to working with you for a long time.
Hi all,
The 1.36.0-wmf.29[0] train is currently blocked at group0 by the
following issue:
* Bug in client error logging stops any errors from being logged in
group 0 wikis
- https://phabricator.wikimedia.org/T277094
Note that we have recently updated the train policy[1] to use
client-side errors as a signal of deployment health.
Jon Robson is working on T277094, and hopes to have a fix yet this
afternoon, but if this is an area you're familiar with, help is likely
welcome.
If all issues are resolved before the cutoff at 15:00 PST, the train
will roll forward today. Otherwise it will resume tomorrow during the
US workday.
As ever, you can follow train progress on Freenode's
#wikimedia-operations as well as on the blocker task[0].
Regards,
-- Your over-communicative train operator
[0]. <https://phabricator.wikimedia.org/T274938>
[1].
<https://wikitech.wikimedia.org/wiki/Deployments/Holding_the_train#Issues_th…>
Hello,
This email contains updates for March 10, 2021
<https://www.mediawiki.org/wiki/Scrum_of_scrums/2021-03-10>.
Cheers,
Deb
2021-03-10Callouts
- SRE ServiceOps Scheduling upgrade of the main codfw kubernetes
cluster. It will be unavailable for a few hours, announcement will be sent
when the exact maint window is decided
- SRE ServiceOps blocked on
- PET on T274262
- Product Infrastructure on T274262
- Analytics on T274262
- Thanks to Language and WMDE for acting on the above task.
No updates
CommTech, Anti-Harassment, Editing, iOS, Android, Language, Inuka, Library
*No notes provided*
Parsing, Cloud, FR-Tech, Performance, QTE, Search, Security
ProductAnti-Harassment Tools
- Thank yous:
- Thanks to Lukasz Sobanski and Amir Sarabadani for writing
documentation on adding DB tables
- Thanks to Timo Tijhof for helping improve the AHT dashboard on
logstash
Growth
- Updates:
- Continuing work on Add Link
https://wikitech.wikimedia.org/wiki/Add_Link
- Continuing to work on exposing more configuration settings to wiki
admins T274520 <https://phabricator.wikimedia.org/T274520> T274031
<https://phabricator.wikimedia.org/T274031>
- Enabling Growth tools on thwiki T274646
<https://phabricator.wikimedia.org/T274646>
Web
- Thank yous:
- Brandon Black for helping with temporarily disabling the edge
caches for a small number of wikis to aid with the Desktop Improvements
rollout
- Noam Rosenthal for helping with various Page Previews performance
improvements and regressions
- Adam Wight for working on centralizing the user edit count
bucketing logic: https://phabricator.wikimedia.org/T210106
- Updates:
- Enabled WVUI search treatment A/B test on more wikis:
https://phabricator.wikimedia.org/T249297
- Focused on the language switcher treatment A/B test:
https://phabricator.wikimedia.org/T268504 and its subtasks
Product Infrastructure
- Blocking:
- SRE ServiceOps on T274262
Structured Data
- Updates:
- Focused on blockers for making MediaSearch the default search UI on
Commons
- Planning and discussion around image recommendations tool
Abstract Wikipedia
- Blocked by:
- None.
- Blocking:
- None known.
- Thank yous:
- Search Platform for on-going discussion around discovery needs and
how to meet them.
- Updates:
- Continuing on phase gamma:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Phases
- The Wikifunctions logo concept vote closes on Monday 2021-03-15:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Wikifunctions_logo_conce…
Language
- Thank yous: From SRE Service Ops for T274262
Vue.js
- Thank yous:
- Timo for code review and getting ES6 support in wikimedia/minifier
over the finish line
- Updates:
- ES6-only module support in ResourceLoader now available ("es6":
true); documentation to come
- Actual support for serving ES6 code is not yet available but very
close, hoping to land it this week. We'll make an announcement and update
documentaton once this is merged
TechnologyAnalytics
- Blocking:
- SRE ServiceOps on T274262
Platform
- Blocking:
- SRE ServiceOps on T274262
Engineering ProductivityRelease Engineering
- Updates:
- Train Health
- Last week: 1.36.0-wmf.33 phab:T274937
<https://phabricator.wikimedia.org/T274937>
- This week: 1.36.0-wmf.34 phab:T274938
<https://phabricator.wikimedia.org/T274938>
- Last week: 1.36.0-wmf.35 phab:T274939
<https://phabricator.wikimedia.org/T274939>
Site Reliability Engineering
- Blocked by:
- PET on T274262
- Product Infrastructure on T274262
- Analytics on T274262
- Blocking:
- None
- Thank yous:
- Updates:
- Scheduling upgrade of the main codfw kubernetes cluster. It will be
unavailable for a few hours, announcement will be sent when the
exact maint
window is decided
- SRE Traffic wiping edge caches on a handful of wikis to aid desktop
refresh testing - https://phabricator.wikimedia.org/T274784
WMDE Technical Wishes
- Thank yous:
- Analytics
- Updates:
- Syntax highlighting “accessible” color schema is ready to test on
the beta cluster
- Tweaking the shared code for edit count bucketing,
https://phabricator.wikimedia.org/T210106
- Still piling up reviews for Analytics.
- Would like to deploy a few non-voting jobs for Quibble+Apache
Cross-cutting
- Blocked by:
- [long term] Search Platform: PHP 8.0 work is long-term blocked on
the migration to ElasticSearch 7.0
https://phabricator.wikimedia.org/T263142
- Updates:
- Working on splitting our front-end JS linting rules into ES5 and
ES6 variants. This will lead to a new release of eslint-config-wikimedia.
- There are a few repos still using jsonlint, notably Wikidata's
data-values/value-view: https://phabricator.wikimedia.org/T220036https://libraryupgrader2.wmcloud.org/library/npm/grunt-jsonlint?branch=mast…
- PHP 8.0 work is focussed on helping upstream provide forwards and
backwards compatibility in Elastica-related PHP code.
- CI tools' upgrade status is adequate:
https://libraryupgrader2.wmcloud.org/status?branch=master
--
deb tankersley (she/her)
senior program manager, engineering
Wikimedia Foundation
Good evening. I am Rightandlight and I am working on the mailing list for global unlocking and unblocking application including conversation page lock on jawp.
Now, on the jawp mailing list, the characters are garbled and I can barely see it in the email, but I can't see it in the archive and it's not seen by many people. Is it possible to eliminate the garbled characters in the jawp mailing list archive?
https://lists.wikimedia.org/pipermail/wikija-l/
Rightandlight
* I am always looking for someone to unlock or help me with global unlocking.
https://ja.wikipedia.org/wiki/%E5%88%A9%E7%94%A8%E8%80%85:%E3%82%A2%E3%83%A…
Greetings,
Starting this month (March 2021) and moving forward, new software features
developed by the Wikimedia Foundation for MediaWiki will no longer support
Internet Explorer 11 (IE11). Existing software features may be deprecated
from IE11 as the browser reaches EOL support from Microsoft. More
information about the reasoning behind this is available on mediawiki.org
[1].
1. https://www.mediawiki.org/wiki/Compatibility/IE11
Sincerely,
--
Keegan Peterzell (he/him)
Technical Collaboration Specialist
Wikimedia Foundation
Hi all,
Since January 2020, Wikimedia has not served traffic to browsers which do
not support TLS 1.2 [0]. We would like to bump basic MediaWiki software
stack support to exclude those very old browsers as well.
Our MediaWiki core, extensions and skins basic browser support matrix still
includes some end-of-life browsers published between 2007 and 2013 that are
only supporting the now insecure ciphers of TLS 1.0 and 1.1.
We've gathered stats [1] emphasizing the relatively small access
expectations. Now we want to push software stack support to align to those
browser versions already in place as minimum in Wikimedia hosted
MediaWikis.
We're continuing to provide support for browsers published from 2013 on!
Note that Internet Explorer 9 and 10 are unaffected by this proposed change
as well for the moment. See the specific list on task. [1]
What's to win:
A great number of design and layout features (CSS, SVG and WAI-ARIA, see
the list [2]) which we currently just exceptionally use in some products or
via extra effort, performance impacting hacks and workarounds, and
maintenance on the developer side.
Current support is slowing down some advances in Desktop Improvements and
other front-end work.
What's to lose:
Possible layout issues in third party MediaWikis still targeting those
end-of-life browers. Content access should be untouched there.
If there are no objections within the next 10 days, we're going to amend
the support matrix with aforementioned TLS 1.2 supporting browsers as the
minimum.
Please let us know about any objections or further inputs, preferably on
task.
Thanks and best regards,
Volker
[0] - https://phabricator.wikimedia.org/T238038
[1] - https://phabricator.wikimedia.org/T238038
[1] - https://phabricator.wikimedia.org/T266866
[2] - https://phabricator.wikimedia.org/T266866#6591703
---
Volker E.
Lead UX Engineer
Desktop Improvements/Design System
Wikimedia Foundation
Hello deployers,
TLDR: We are upgrading deployment servers, both physical hardware
(older R430-> newer R440) and OS version (stretch->buster) [1]
What happened so far:
Today we switched the deployment server and scap master for codfw from
deploy2001 to deploy2002. [2]
What happens next:
On Monday, March 1st, we want to switch the deployment server and scap
master for eqiad from deploy1001 to deploy1002. [3][4]
The window is "20:00–22:00 UTC # 12:00–14:00 PST" after the morning
backport window for up to 2 hours. In this time you won't be able to
deploy.
https://wikitech.wikimedia.org/wiki/Deployments#Monday,_March_01
Do you have to do anything?
If you connect to "deployment.eqiad.wmnet" the host key will change,
you can use the scripts to update host keys though and the
fingerprints are also on wiktech on new (and protected) pages. [5]
Yes, you'll have to retrain muscle memory to switch to deploy1002,
sorry for that but it's just a new generation every couple of years
and this way we can also fall back to something if needed. In return
you should get more performance from the new hardware.
No, you don't need to worry about losing data in your home dir,
everything has been rsynced over straight into /home on these hosts.
Let us know if you have any questions,
Daniel & Mukunda
[1] https://phabricator.wikimedia.org/T265963
[2] https://gerrit.wikimedia.org/r/c/operations/puppet/+/667043
[3] https://wikitech.wikimedia.org/wiki/Deployments#Monday,_March_01
[4] https://gerrit.wikimedia.org/r/q/topic:%22deployment-switch%22+(status:open)
[5] https://wikitech.wikimedia.org/wiki/Deploy1002
--
Daniel Zahn <dzahn(a)wikimedia.org>
Operations Engineer