Wikitech-l January 2025

33 participants
45 discussions

Maintenance scripts are moving to Kubernetes
by Reuven Lazarus 07 May '25

07 May '25

Hi all, With MediaWiki at the WMF moving to Kubernetes, it's now time to start running manual maintenance scripts there. Any time you would previously SSH to a mwmaint host and run mwscript, follow these steps instead. The old way will continue working for a little while, but it will be going away. What's familiar: Starting a maintenance script looks like this: rzl@deploy2002:~$ mwscript-k8s --comment="T341553" -- Version.php --wiki=enwiki Any options for the mwscript-k8s tool, as described below, go before the --. After the --, the first argument is the script name; everything else is passed to the script. This is the same as you're used to passing to mwscript. What's different: - Run mwscript-k8s on a deployment host, not the maintenance host. Either deployment host will work; your job will automatically run in whichever data center is active, so you no longer need to change hosts when there’s a switchover. - You don't need a tmux. By default the tool launches your maintenance script and exits immediately, without waiting for your job to finish. If you log out of the deployment host, your job keeps running on the Kubernetes cluster. - Kubernetes saves the maintenance script's output for seven days after completion. By default, mwscript-k8s prints a kubectl command that you (or anyone else) can paste and run to monitor the output or save it to a file. - As a convenience, you can pass -f (--follow) to mwscript-k8s to immediately begin tailing the script output. If you like, you can do this inside a tmux and keep the same workflow as before. Either way, you can safely disconnect and your script will continue running on Kubernetes. rzl@deploy2002:~$ mwscript-k8s -f -- Version.php --wiki=testwiki [...] MediaWiki version: 1.43.0-wmf.24 LTS (built: 22:35, 23 September 2024) - For scripts that take input on stdin, you can pass --attach to mwscript-k8s, either interactively or in a pipeline. rzl@deploy2002:~$ mwscript-k8s --attach -- shell.php --wiki=testwiki [...] Psy Shell v0.12.3 (PHP 7.4.33 — cli) by Justin Hileman > $wmgRealm = "production" > rzl@deploy2002:~$ cat example_url.txt | mwscript-k8s --attach -- purgeList.php [...] Purging 1 urls Done! - Your maintenance script runs in a Docker container which will not outlive it, so it can't save persistent files to disk. Ensure your script logs its important output to stdout, or persists it in a database or other remote storage. - The --comment flag sets an optional (but encouraged) descriptive label, such as a task number. - Using standard kubectl commands[1][2], you can check the status, and view the output, of your running jobs or anyone else's. (Example: `kube_env mw-script codfw; kubectl get pod -l username=rzl`) [1]: https://wikitech.wikimedia.org/wiki/Kubernetes/Kubectl [2]: https://kubernetes.io/docs/reference/kubectl/quick-reference/ What's not supported yet: - Maintenance scripts launched automatically on a timer. We're working on migrating them -- for now, this is for one-off scripts launched by hand. - If your job is interrupted (e.g. by hardware problems), Kubernetes can automatically move it to another machine and restart it, babysitting it until it completes. But we only want to do that if your job is safe to restart. So by default, if your job is interrupted, it will stay stopped until you restart it yourself. Soon, we'll add an option to declare "this is idempotent, please restart it as needed" and that design is recommended for new scripts. - No support yet for mwscriptwikiset, foreachwiki, foreachwikiindblist, etc, but we'll add similar functionality as flags to mwscript_k8s. Your feedback: Let me know by email or IRC, or on Phab (T341553 <https://phabricator.wikimedia.org/T341553>). If mwscript-k8s doesn't work for you, for now you can fall back to using the mwmaint hosts as before -- but they will be going away. Please report any problems sooner rather than later, so that we can ensure the new system meets your needs before that happens. Thanks, Reuven, for Service Ops SRE

7 19

Several database changes happening in the coming months
by Amir Sarabadani 24 Apr '25

24 Apr '25

Hello, in the next coming months, these changes will happen in databases and the infrastructure. And it might affect you if you rely on them in your tools or queries. This list is ordered based on how soon the change will happen. We understand that updating your tools and systems can be time consuming, hence we are giving an advanced notice. I truly apologize for the inconvenience but many of these changes are needed to keep the site running smoothly. Image table redesign Around fourteen years after the creation of T28741 <https://phabricator.wikimedia.org/T28741>, we are implementing the changes described therein. Currently, every current version of an image has a row in the image table and if there are older versions of that file, those rows could be found in the oldimage table. These two tables (image and oldimage) will be dropped in around two months. The replacement will be two main tables: file and filerevision. Every file will have a row in the file table describing the name and the type. Every version of the file (current and old) will have a row in filerevision describing the file-specific information such as its size or the hash of the file, similar to the existing distinction between pages and revisions. Another improvement is that every file and file revision will get a unique auto increment id simplifying many operations and queries. You can check T28741 <https://phabricator.wikimedia.org/T28741> for more information. The new tables are already accessible in wikireplicas but the data hasn’t been fully migrated yet. Term store split out of wikidata’s database Wikidata’s database has been growing too fast and we need to move the term store (tables starting with wbt_) to a dedicated cluster to allow growth and improve wikidata’s performance by utilizing cache locality. The new section will be called x3 and you will be able to access it in wikireplicas but this also means you won’t be able to join these tables with the rest of wikidata’s database (such as page table) since they will be residing in two physically separate servers that also means most of your queries to wikidata’s database (and term store) will become faster. We are aiming for the switch to happen in three months’ time. You can follow the work in T351820 <https://phabricator.wikimedia.org/T351820>. Additionally, wb_type table will be dropped and the mapping will be hard-coded in the code instead. See gerrit:1110810 <https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/1110810> for more details. This helped us simplify a lot of Wikibase code (example <https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/1110720>). Categorylinks normalization Categorylinks is the next table in the series of links tables being normalized via the linktarget table (parent ticket <https://phabricator.wikimedia.org/T300222>, RFC <https://phabricator.wikimedia.org/T222224>). Similar to templatelinks and pagelinks tables, cl_to will be dropped and instead the new field cl_target_id will point to lt_id in the linktarget table. We will also drop the cl_collation field and replace it with cl_collation_id which will point to the collation_id field on the new table we are introducing called collation. We are aiming to get this fully done by the end of the next quarter (end of June 2025) but it depends on how fast the migration script can operate and that’s outside of our control. You can follow the work in T299951 <https://phabricator.wikimedia.org/T299951>.It’s worth noting that after this migration is done, we will start working on the imagelinks table. Thank you -- *Amir Sarabadani (he/him)* Staff Database Architect Wikimedia Foundation <https://wikimediafoundation.org/>

1 1

Excited to Contribute to Wikimedia Foundation
by nidha ahmed 17 Apr '25

17 Apr '25

Hi Sir/Madam, I hope you’re doing well. I am Nidha Ahmed, and a junior undergraduate student studying Artificial Intelligence and Data Science. I’m also going to join Google as an SWE Intern next summer. I’ve always been a huge admirer of the Wikimedia Foundation and its mission to make free educational content accessible to everyone. It’s incredible how your work empowers millions of learners around the globe, and I’m very eager to be part of this impact. I have experience with JavaScript, HTML, CSS, jQuery, ReactJS, and Python, and I’ve dabbled a bit in Android development as well. While I’m new to PHP and Ruby on Rails, I’m super excited to learn them! If you could share some resources or tips to get started with these technologies, it would be a huge help. A little about me: I’ve worked on projects like a movie recommendation system, a text summarization web app, and a geospatial analysis tool for public health. I’ve also contributed to open-source initiatives like designing real-time heatmaps for SoundScape. I’m looking to grow my skill set, hence I’m so drawn to Wikimedia. It would be helpful for me to get guidance on how to start contributing. I’m genuinely excited about the chance to learn from your community and support your amazing mission. I'm attaching my resume below for reference and proofs. Looking forward to hearing from you! Best regards, Nidha Ahmed Mohammad.

3 2

Database dumps
by Byrial Jensen 17 Apr '25

17 Apr '25

Until some weeks ago http://dumps.wikimedia.org/backup-index.html used to show 4 dumps in progress at the same time. That meant that new database dumps normally was available within about 3 weeks for all databases except for enwiki and maybe dewiki where the dump process due to size took longer time. However the 4 dumps processes at one time become 3 some weeks ago. And after massive failures at June 4, only one dump has been in progress at the same time. So at the current speed it will take several months to come thru all dumps. Is it possible to speed up the process again using several dump processes at the same time? Thank you, Byrial

3 2

User-Agent:
by Domas Mituzas 17 Apr '25

17 Apr '25

Hi! from now on specific per-bot/per-software/per-client User-Agent header is mandatory for contacting Wikimedia sites. Domas

19 61

API issue
by ovskmendov＠proton.me 17 Apr '25

17 Apr '25

Whenever I access the API, I get "Wikimedia Error: Our servers are currently under maintenance or experiencing a technical problem." Sometimes if I wait a bit, I'll get a few good requests, but it will shortly go back to the previous message. My code was working just fine a few days ago and I didn't change anything. Sent with [Proton Mail](https://proton.me/) secure email.

7 12

Acquiring list of templates including external links
by Takashi OTA 17 Apr '25

17 Apr '25

Hoi, This is an inquiry from my friend in academia, researching about Wikipedia. He would like to know whether there's a way to acquire a list of templates including external links. Here are some examples including external links. https://ja.wikipedia.org/wiki/Template:JOI/doc https://ja.wikipedia.org/wiki/Template:Twitter/doc Such links are stored in externallinks.sql.gz, in an expanded form. When you want to check increase/decrease of linked domains in chronological order through edit history, you have to check pages-meta-history1.xml etc. In a such case, traditional links and links by templates are mixed, Therefore, the latter ones (links by templates) should be expanded to traditional link forms. Sorry if what I am saying does not make sense. Thanks in advance, --Takashi Ota [[U:Takot]]

13 24

2025 Wikimedia Hackathon - registration is now open
by Deb Tankersley 02 Apr '25

02 Apr '25

*Registration for the 2025 Wikimedia Hackathon is now open! * *(with apologies for cross-posting)* The annual Wikimedia Hackathon <https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2025> is organized by the Wikimedia Foundation <https://wikimediafoundation.org/> in collaboration with Wikimedia User Group Turkey (WMTR) <https://meta.wikimedia.org/wiki/Wikimedia_Community_User_Group_Turkey> and will be taking place in Istanbul, Turkey, from May 2nd through May 4th, 2025 at the Renaissance Polat Istanbul Hotel <https://www.marriott.com/en-us/hotels/istrn-renaissance-polat-istanbul-hote…> . The Hackathon is an on-site, in-person event. Those people who cannot attend the Hackathon in-person will be able to follow some of the program content online, but should not register using the link provided below. More information will be provided closer to the event on how to participate remotely. Registration will be open until mid April 2025, or until we reach event capacity. The Hackathon event is free for all* to attend *and each person that attends the Hackathon is required to register. - Catering (lunch, dinner, snacks, and drinks) will be provided during the event. - Covid-related equipment will also be available upon request (e.g. self test kits and masks). - We’ll have discounted room codes for those that want to stay at the hotel venue, to be announced in the coming weeks. - Check if your passport is up to date and if you will need a visa (or an e-visa) to travel to Turkey, citizens of most countries can apply for an e-visa online <https://www.mfa.gov.tr/visa-information-for-foreigners.en.mfa>. Participants are expected to book their own travel arrangements and accommodation. However, the Wikimedia Foundation is offering to take care of travel and accommodation for a limited number of scholars and you will be able to apply for a scholarship during the registration process. Scholarship applicants - please note: - *Scholarship application and Wikimedia Foundation staff sponsorship will only be available to request until December 10th, 2024. * - Priority will be given to scholars who can mentor or support in areas of high demand and staff with ambitious or impactful projects. - Those that have requested a scholarship or sponsorship will be notified by mid to late December 2024 about the status of their application. - All scholarships provided will adhere to the WMF travel policy <https://foundation.wikimedia.org/wiki/Policy:Scholarship_travel_policy> guidelines. *Scholarship to this event will cover:* - Roundtrip airfare between your city of residence and Istanbul, Turkey - arriving on May 1, 2025 and departing on May 5, 2025. - Private accommodation at the conference hotel for up to 4 nights - Medical Insurance Coverage for any scholars traveling outside of their home country. (Scholars local to Turkey will need to use their regular insurance coverage.). - Airport transfers between the Istanbul Airport (IST) and the conference hotel. - All meals will be provided for the duration of the event (lunch, drinks, snacks, and dinner will be provided on event days; breakfast will be provided by the hotel for guests staying there). In addition, dinner will be provided on Thursday before the Hackathon officially kicks off. - Fees associated with obtaining a visa to travel to Turkey (visa application fees, and travel to in-person travel visa appointment (if needed)). - Citizens of most countries can apply for an e-visa online <https://www.mfa.gov.tr/visa-information-for-foreigners.en.mfa>. *Scholarship to this event will not cover:* - Per diem costs on travel days. - Ground transportation costs between your residence and home airport. - Insurance for your personal possessions. The Hackathon registration form runs on Pretix (a free, open-sourced third-party platform that helps organize and manage events) which may subject your data to additional terms <https://pretix.eu/about/en/privacy>. For more information on WMF’s privacy and data-handling for the Hackathon, please read the privacy statement <https://foundation.wikimedia.org/wiki/Legal:Wikimedia_Hackathon_Privacy_Sta…> . <https://pretix.eu/wikimedia/hackathon2025> If you encounter any issues while registering, or have questions about the registration process, feel free to contact the coordination team at hackathon(a)wikimedia.org. Cheers, Deb -- deb tankersley (she/her) developer outreach program management Wikimedia Foundation

1 1

EBNF grammar project status?
by Steve Bennett 01 Apr '25

01 Apr '25

What's the status of the project to create a grammar for Wikitext in EBNF? There are two pages: http://meta.wikimedia.org/wiki/Wikitext_Metasyntax http://www.mediawiki.org/wiki/Markup_spec Nothing seems to have happened since January this year. Also the comments on the latter page seem to indicate a lack of clear goal: is this just a fun project, is it to improve the existing parser, or is it to facilititate a new parser? It's obviously a lot of work, so it needs to be of clear benefit. Brion requested the grammar IIRC (and there's a comment to that effect at http://bugzilla.wikimedia.org/show_bug.cgi?id=7 ), so I'm wondering what became of it. Is there still a goal of replacing the parser? Or is there some alternative plan? Steve

26 217

Sunsetting recommendation-api from current Wikimedia offerings
by Alexandros Kosiaris 31 Mar '25

31 Mar '25

Hi everyone, Summary After a long series of consultations with various teams in the Wikimedia Foundation, I find myself happy to inform you of the sunset of an API from the current Wikimedia offerings. That would be *recommendation-api*, the one powering *https://<project_domain>/api/rest_v1/#/Recommendation* family of endpoints, e.g. https://commons.wikimedia.org/api/rest_v1/#/ or https://en.wikipedia.org/api/rest_v1/#/Recommendation. The codebase of that API resides in *https://gerrit.wikimedia.org/g/mediawiki/services/recommendation-api <https://gerrit.wikimedia.org/g/mediawiki/services/recommendation-api>*. The removal date will be 2025-03-31. There is some more information below as to why, what and how as well as an estimation of the impact this is expected to have (minimal to zero). It is also my intention to proceed with a diff <https://diff.wikimedia.org/> post explaining our process in more detail. Intro Recommendation-api was being used solely by the Wikipedia official Android application. Given that recently <https://phabricator.wikimedia.org/T373611>, the Android Wikipedia Official application has moved away from using this API, the SRE team wanted to remove this service from production to focus on more impactful services. The problem was ensuring that we turn off this API responsibly so that we do not have a significant impact on users who have not yet upgraded their apps and do not waste SRE effort on supporting a service we are moving away from, for more than we need to. A complication was that the service wasn't anymore owned by anyone, meaning maintenance (Node.js and Operating System upgrades) had to be carried out by people that were not acquainted at all with the code base. Process To achieve the above goals, a process was jump started by a group of Principal Engineers in the Foundation (Jon Robson, Moriel Schottlender and yours truly) collecting data and feedback regarding the remaining usage of the API as well as the estimated amount of effort that would be needed to continue maintaining the service vs sunsetting it. Since October, we spoke to various stakeholders in the Foundation to figure out the best possible plan, going through a variety of possible paths. We ended up recommending that the service be sunset at 2025-03-31, a recommendation that was accepted. Impact The service is only accessed by users of the Wikipedia Android application. Recent versions of it no longer rely on it and there will be zero (0) impact on users of these. But users with application versions older than 6 months by the time of removal (2025-03-31), will see reduced functionality in the form of the *Suggested Edits* part of the application no longer functioning. The rest of the application will continue to function as usual. We encourage users of versions older than *r/2.7.50504-r-2024-10-01 <https://github.com/wikimedia/apps-android-wikipedia/releases/tag/r%2F2.7.50…>* to update. We wanted to make sure we don't break 3rd party users without giving them a heads up. Going through access logs and metrics, we identified no valid 3rd party users. Furthermore, we intend to review traffic/errors to that API 1 month past the cutoff date and evaluate the effectiveness of our solution. Note This API should not be confused with another one, also named recommendation-api <https://gerrit.wikimedia.org/r/plugins/gitiles/research/recommendation-api/>, and exposed by LiftWing, under the https://api.wikimedia.org/wiki/Lift_Wing_API/Reference/Get_content_translat… endpoint. The latter is powered by a different codebase and, conflicting naming aside, has no other relation to the former or this sunsetting. Regards, -- Alexandros Kosiaris Principal Site Reliability Engineer Wikimedia Foundation

1 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l January 2025