Change 924608 merged by Dzahn:

[operations/puppet@production] gerrit/bacula: adjust Gerrit file paths to be backed up

https://gerrit.wikimedia.org/r/924608

Change 924608 merged by Dzahn:

[operations/puppet@production] gerrit/bacula: adjust Gerrit file paths to be backed up

https://gerrit.wikimedia.org/r/924608

This was being added by me in the past using http://maps.wikimedia.org/osm-intl/%7Bz%7D/%7Bx%7D/%7By%7D.png

I am breaking out the ones that sre-collab can fix into a subtask. After that there are a handful for observability (thanos, prometheus, graphite, icinga), webperf, ircd and the single apache2.conf.erb for Mediawiki and that would be it. It doesn't seem _that_ much to me, actually.

If we've removed it in MW 1.40/master , I wonder if it's worth backporting to the releases.... Certainly maybe 1.39 being an LTS. 1.38 maybe not as it's due to become EOL this month.

Change 926604 merged by jenkins-bot:

[mediawiki/extensions/WikimediaEvents@master] networkprobe: Use mw.user.getPageviewToken instead of Math.random

https://gerrit.wikimedia.org/r/926604

Sorry, I'm declaring this Invalid, because I haven't heard of this happening anywhere else, and I can't imagine how this could happen. My guess is that the Cargo DB password just changed somehow, independently of the deletion attempt or anything else - and changing the password again just fixed the problem. Feel free to re-open this, though, if you think it's a real bug.

maps.wikimedia.org tiles may only be used by Wikimedia wikis, and sites hosted by Wikimedia Affiliates.
— https://wikitech.wikimedia.org/wiki/Maps/External_usage

Change 926626 had a related patch set uploaded (by Kimberly Sarabia; author: Kimberly Sarabia):

[operations/mediawiki-config@master] Remove VectorLimitedWidthIndicator

https://gerrit.wikimedia.org/r/926626

We are done with our first production level Iceberg table! 🎉 🎉 🎉

Please can we avoid using ableist language such as "sane" as per https://www.mediawiki.org/wiki/Inclusive_language

A few brief thoughts (please let me know if any need elaboration!)

• In T337294 I like the first screenshot which combines the 2 pages (Contribute & Contributions) into a single page, for 2 main reasons:
  • "Scrolling" is inherently easier & faster than "Clicking a link and waiting for the new page to load".
  • It's easy to ignore things that are hidden (collapsed, or in a tab). If new-users are less likely to stumble upon Special:Contributions, then they are less likely to benefit from it (i.e. spontaneously adopt the workflows that many experienced editors use this page for).
• As a highly-active editor, the Special:Contributions/MYNAME link is one of my most-used. I use it many times each day. The Vector-2022 placement of it within a dropdown menu frustrated me, and I now use User-JS/CSS to forcibly add it into the Personal-bar, for 1-click access. Screenshot: F37091403 .
  • I also personally know of a few editors who use it as their primary "attention list" page, and/or their primary access point for the sites, who would be very frustrated if it became harder to access.
• I think there's also likely to be widespread confusion about the overlap between Special:Homepage and Special:Contribute. I wonder how the Special:Homepage is planned to be expanded in the years ahead, and if all these entry points could link there instead? I.e. Keep the compressed short-reminder links (as in F37029989), but link all of them to Special:Homepage where they would contain the more elaborated descriptions (as in F37029987).

Hope that helps!

kindrobot merged https://gitlab.wikimedia.org/repos/abstract-wiki/aw-ci-chart/-/merge_requests/18

When I checked for that page that got deleted in svwiktatiory, they were indeed moved by me. My guess is that they were invalid legacy encoding which would have not caused an error but when moved to utf-8, the check became strict which is fine in some cases but not all. I looked for any mediawiki page in nlwiki to make sure I won't break the wiki: T128154#8899826 I'll go and manually edit those 10 pages to fix their encoding.

I have started the general documentation effort by creating an Iceberg page here https://wikitech.wikimedia.org/wiki/Analytics/Systems/Cluster/Iceberg.

These pages in mw ns actually on legacy encoding but on their latest version meaning it might break the wiki if I move them (and if they have invalid utf-8):

+--------------------+
| page_title         |
+--------------------+
| Watchmethod-recent |
| Watchmethod-list   |
| Sig_tip            |
| Nstab-wp           |
| Portal-url         |
| Allarticles        |
| Media_tip          |
| Math_sample        |
| Math_syntax_error  |
| Ipb_expiry_invalid |
+--------------------+
10 rows in set (5.995 sec)

Change 926624 had a related patch set uploaded (by Arlolra; author: Arlolra):

[mediawiki/core@master] Try to getContent to check for a badrevision exception

https://gerrit.wikimedia.org/r/926624

Changing the date range from 2018-05-02 - 2023-05-01 to 2022-05-01 - 2023-05-01 (5 years of data down to 1 year of data) makes some difference in a direct query test, but not a particularly large difference. The 5 year query in T338055#8899789 took 8.546 seconds. The 1 year query is returning for me in 6.258 seconds. The 1 year query is an order of magnitude less data (285073 rows).

Change 926622 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/extensions/WikimediaIncubator@master] Hooks: Change onPageContentLanguage() to not use $userLang

https://gerrit.wikimedia.org/r/926622

Just to clarify the above log relates to an issue connecting to manila-sharecontroller.cloudinfra-codfw1dev (185.15.57.5) from cloudweb2002-dev (208.80.153.41).

Change 926621 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/extensions/LiquidThreads@master] LqtDispatch: Change onPageContentLanguage() to not use $userLang

https://gerrit.wikimedia.org/r/926621

Checked Hawaiian Wikipedia haw, Icelandic Wikipedia is, Inuktitut Wikipedia iu, and Javanese Wikipedia jv - all works as expected.

Thanks to the work of @Cstone and @jgleeson and @AnnWF we're back in business! Copying the job data summary for the Unsubscribes-* List to celebrate because we now have a reduction of bad data (it was 520 and now it's 3, yay!) The rest of the jobs for DatabaseUpdate-*, Optout-*, and the new ChecksumEmails-* have processed successfully. Thanks team!

If we do not resolve non-local page IDs, would it suffice to pass the iw_prefix for now (to indicate that this is non-local), instead of trying to map this to a domain/project (which obviously can't be done reliably at the moment)?

Alright, so if we reduce the scope from general link to page link -- that is a link to wiki page, either local or in another wiki -- you would be fine with the schema we sketched up above, @Ottomata? If so, I'd adapt my change request accordingly.

Change 926620 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/extensions/PageLanguage@master] Hooks: Remove unused $userLang arg from onPageContentLanguage()

https://gerrit.wikimedia.org/r/926620

I overall think this is a great idea. However, I think on ENWIKI, it would be helpful to allow edit filter managers to edit the special:BlockedExternalDomains.

Sorry to keep on at this, but the difference between a low-teens count from one of my earlier tests and 50+ seems to be "Apply general fixes", which was turned off in the former case. That makes some kind of sense.

Current stuff left to implement:

• Diff module requested at https://nap.wikisource.org/wiki/Wikisource:Prugetto:Tecnicismi#Edit_pages_in_sequence (doing)
• Fallback text module (API has been created, integration with EIS still needs to be finished)

In T337041#8891560, @Jelto wrote:

@Dzahn can you archive the project and put a [ARCHIVED], moved to https://gitlab.wikimedia.org/repos/sre/miscweb/annualreport/ in the project description?

dancy merged https://gitlab.wikimedia.org/repos/releng/gitlab-settings/-/merge_requests/23

Okay thanks for correcting that part.

Change 907830 merged by jenkins-bot:

[labs/tools/VideoCutTool@master] Add nginx support to dev env

https://gerrit.wikimedia.org/r/907830

Thanks @Dzahn, I'll open a ticket with ITS to investigate.

topranks> Cathal Mooney Pings are being blocked by 185.15.57.5 itself it seems:
1:39 PM https://www.irccloud.com/pastebin/TZm8TF4e/
Plain Text • 4 lines raw | line numbers
1:40 PM i.e. they are getting there but it's sending unreachable messages back
1:40 PM traffic does seem to get beyond the cloudgw
1:41 PM https://www.irccloud.com/pastebin/Dki06Xhv/
Plain Text • 8 lines raw | line numbers
1:46 PM They seem to be making it to cloudnet/neutron, which is generating the rejects:
1:46 PM https://www.irccloud.com/pastebin/PZTwUGW0/
Plain Text • 9 lines raw | line numbers
1:47 PM Not sure if that helps. What I can say is that nothing here is using the 172.20.x addressing, or this is not being affected by the new cloud-private networking.
1:47 PM cloudweb, cloudgw and cloudnet are on their existing addresses that they were prior to starting any of this
1:49 PM Seems there is a NAT rule to forward this traffic to/from VM IP 172.16.128.97
1:49 PM But that IP is unreachable from the cloudnet for some reason
1:50 PM root@cloudnet2005-dev:/home/cmooney# ip neigh show 172.16.128.97
1:50 PM 172.16.128.97 dev qr-21e10025-d4 FAILED
1:51 PM It can ping other VMs so I think the issue isn't with cloudnet2005 connection to the instance vlan
1:51 PM https://www.irccloud.com/pastebin/vSa9SoOM/
Plain Text • 4 lines raw | line numbers
1:53 PM TL;DR - I don't think this is a physical network issue, and it's not using any of the new components
1:57 PM cloudnet2005-dev can't reach VM tools-codfw1dev-bastion-2 for some reason

Change 926612 merged by jenkins-bot:

[openstack/horizon/wmf-puppet-dashboard@main] instance tab: catch exceptions when loading prefixes

https://gerrit.wikimedia.org/r/926612

iegreview and racktables have both been decom'ed meanwhile. Adding tickets and checking boxes.

• @dchen is going to take over this effort moving forward
• we plan to wrap up this first round of research by end of June and publish an insights report

I recommend moving forward with a single model.
The link-based model has worked well in my experience and it is noted as useful for both analytics and features cases. Thus, I recommend moving forward with the link-based model.

I'm marking this as Invalid - I don't know if this is still an issue, but I don't see how this could be a Page Forms bug - the problem has to be, or has to have been, in Semantic Forms Select.

This is not true (at least on enwiki), for the "disallow" action; a filter set to true will stop 100% of edits, until it is disabled. And this is a good thing, because sometimes when we're being attacked by proxies, the attacker's edits make up a substantial portion of recentchanges.

Please look at AbuseFilterEmergencyDisableThreshold configuration. I don't know where are you getting this but it exists.

In T337047#8898410, @Jelto wrote:

The last part is archive the gerrit project https://gerrit.wikimedia.org/r/plugins/gitiles/wikimedia/campaigns/eswiki-2018/. (Setting it read-only and put a [ARCHIVED], moved to https://gitlab.wikimedia.org/repos/sre/miscweb/bienvenida/ in the project description).

Thank you for doing this, @Zabe !

Change 926617 had a related patch set uploaded (by Clare Ming; author: Clare Ming):

[operations/mediawiki-config@master] Add initial stream configs for Android article events using Metrics Platform

https://gerrit.wikimedia.org/r/926617