User Details
- User Since
- Aug 21 2020, 11:05 AM (205 w, 6 d)
- Availability
- Available
- IRC Nick
- urbanecm
- LDAP User
- Urbanecm work
- MediaWiki User
- Martin Urbanec (WMF) [ Global Accounts ]
Yesterday
Ok, disappeared from both https://analytics.wikimedia.org/published/datasets/one-off/research-mwaddlink/wikis.txt and https://analytics.wikimedia.org/published/datasets/one-off/research-mwaddlink/. Removed from the API service as well:
@KStoller-WMF Leaving it for you to prioritise as needed. Technically, the deployment would be non-trivial, as we also need to fit T371602: Regenerate wiki_sections.jsonl to include newly-created wikis in beforehand.
[urbanecm@stat1008 /home/mgerlach/REPOS/mwaddlink-gerrit]$ WIKI_ID=akwiki ./unpublish-datasets.sh [...] akwiki has been delisted from the index. [urbanecm@stat1008 /home/mgerlach/REPOS/mwaddlink-gerrit]$ WIKI_ID=nawiki ./unpublish-datasets.sh [...] nawiki has been delisted from the index. [urbanecm@stat1008 /home/mgerlach/REPOS/mwaddlink-gerrit]$ published-sync /usr/bin/flock -n /var/lock/published-sync -c /usr/bin/rsync -rptL -v --delete /srv/published/ analytics-web.discovery.wmnet::published-destination/stat1008// sending incremental file list deleting datasets/one-off/research-mwaddlink/nawiki/nawiki.w2vfiltered.sqlite.gz deleting datasets/one-off/research-mwaddlink/nawiki/nawiki.w2vfiltered.sqlite.checksum deleting datasets/one-off/research-mwaddlink/nawiki/nawiki.redirects.sqlite.gz deleting datasets/one-off/research-mwaddlink/nawiki/nawiki.redirects.sqlite.checksum deleting datasets/one-off/research-mwaddlink/nawiki/nawiki.pageids.sqlite.gz deleting datasets/one-off/research-mwaddlink/nawiki/nawiki.pageids.sqlite.checksum deleting datasets/one-off/research-mwaddlink/nawiki/nawiki.linkmodel.json.checksum deleting datasets/one-off/research-mwaddlink/nawiki/nawiki.linkmodel.json deleting datasets/one-off/research-mwaddlink/nawiki/nawiki.anchors.sqlite.gz deleting datasets/one-off/research-mwaddlink/nawiki/nawiki.anchors.sqlite.checksum deleting datasets/one-off/research-mwaddlink/nawiki/lr_nawiki_w2vfiltered.sql.gz.checksum deleting datasets/one-off/research-mwaddlink/nawiki/lr_nawiki_w2vfiltered.sql.gz deleting datasets/one-off/research-mwaddlink/nawiki/lr_nawiki_redirects.sql.gz.checksum deleting datasets/one-off/research-mwaddlink/nawiki/lr_nawiki_redirects.sql.gz deleting datasets/one-off/research-mwaddlink/nawiki/lr_nawiki_pageids.sql.gz.checksum deleting datasets/one-off/research-mwaddlink/nawiki/lr_nawiki_pageids.sql.gz deleting datasets/one-off/research-mwaddlink/nawiki/lr_nawiki_anchors.sql.gz.checksum deleting datasets/one-off/research-mwaddlink/nawiki/lr_nawiki_anchors.sql.gz deleting datasets/one-off/research-mwaddlink/nawiki/README deleting datasets/one-off/research-mwaddlink/nawiki/ deleting datasets/one-off/research-mwaddlink/akwiki/lr_akwiki_w2vfiltered.sql.gz.checksum deleting datasets/one-off/research-mwaddlink/akwiki/lr_akwiki_w2vfiltered.sql.gz deleting datasets/one-off/research-mwaddlink/akwiki/lr_akwiki_redirects.sql.gz.checksum deleting datasets/one-off/research-mwaddlink/akwiki/lr_akwiki_redirects.sql.gz deleting datasets/one-off/research-mwaddlink/akwiki/lr_akwiki_pageids.sql.gz.checksum deleting datasets/one-off/research-mwaddlink/akwiki/lr_akwiki_pageids.sql.gz deleting datasets/one-off/research-mwaddlink/akwiki/lr_akwiki_anchors.sql.gz.checksum deleting datasets/one-off/research-mwaddlink/akwiki/lr_akwiki_anchors.sql.gz deleting datasets/one-off/research-mwaddlink/akwiki/akwiki.w2vfiltered.sqlite.gz deleting datasets/one-off/research-mwaddlink/akwiki/akwiki.w2vfiltered.sqlite.checksum deleting datasets/one-off/research-mwaddlink/akwiki/akwiki.redirects.sqlite.gz deleting datasets/one-off/research-mwaddlink/akwiki/akwiki.redirects.sqlite.checksum deleting datasets/one-off/research-mwaddlink/akwiki/akwiki.pageids.sqlite.gz deleting datasets/one-off/research-mwaddlink/akwiki/akwiki.pageids.sqlite.checksum deleting datasets/one-off/research-mwaddlink/akwiki/akwiki.linkmodel.json.checksum deleting datasets/one-off/research-mwaddlink/akwiki/akwiki.linkmodel.json deleting datasets/one-off/research-mwaddlink/akwiki/akwiki.anchors.sqlite.gz deleting datasets/one-off/research-mwaddlink/akwiki/akwiki.anchors.sqlite.checksum deleting datasets/one-off/research-mwaddlink/akwiki/README deleting datasets/one-off/research-mwaddlink/akwiki/ datasets/one-off/research-mwaddlink/ datasets/one-off/research-mwaddlink/wikis.txt
Okay, I can't really debug this without a trace, so I obtained it by temporarily turning wgShowExceptionDetails to true at a mwdebug server. From there, I got the following:
Wed, Jul 31
Okay, jobs should now be back. @Dreamy_Jazz can now login to checkuserwiki with no issues, and as far as I can see, other jobs on private wikis do their job as well.
FTR, this broke all jobs at private wikis (T371433: JobQueueError: Could not enqueue jobs). I re-enabled mediawiki_eventbus via https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1058582 to unbreak stuff, and jobs appear to be back.
As I noted on Gerrit, the change to CommunityConfiguration looks good. However, renaming skipDashboardListing to excludeFromUI is technically a breaking change. You'd need to ensure GrowthExperiments doesn't break during the process. A safe way to do that would be to have three patches:
Tue, Jul 30
Revalidation is now in progress. I estimate it will take two to three days to finish. Once that, we should be good to enable the frontend flag. Moving to Blocked in the meantime.
I was considering whether to run revalidation for everything, or just for few tasks.
[urbanecm@mwmaint1002 ~]$ mwscript extensions/GrowthExperiments/maintenance/refreshLinkRecommendations.php --wiki=enwiki Refreshing link recommendations... processing topic biography... no new tasks needed processing topic women... no new tasks needed processing topic food-and-drink... no new tasks needed processing topic internet-culture... no new tasks needed processing topic linguistics... no new tasks needed processing topic literature... no new tasks needed processing topic books... no new tasks needed processing topic entertainment... no new tasks needed processing topic films... no new tasks needed processing topic media... no new tasks needed processing topic music... no new tasks needed processing topic radio... no new tasks needed processing topic software... no new tasks needed processing topic television... no new tasks needed processing topic video-games... no new tasks needed processing topic performing-arts... no new tasks needed processing topic philosophy-and-religion... no new tasks needed processing topic sports... ^C [urbanecm@mwmaint1002 ~]$
[urbanecm@mwmaint1002 ~]$ mwscript extensions/GrowthExperiments/maintenance/refreshLinkRecommendations.php --wiki=hywwiki Disabled [urbanecm@mwmaint1002 ~]$
I looked into this, and the task is relatively straightforward. Moving to sprint.
Mon, Jul 29
Re-applied hack from T277206#7015609:
have someone with the needed rights edit https://en.wikipedia.org/wiki/MediaWiki:GrowthExperimentsSuggestedEdits.json to set "link_recommendation -> disabled" to "true" (because the configuration defaults to it being enabled)
@Trizek-WMF @KStoller-WMF Unfortunately, we will have to solve this before we can finish T370802: Add a link (Structured task): Release as "turned off" to English Wikipedia.
So...the only missing bit is /usr/local/lib/nagios/plugins/check_confd_template, which is supposed to be populated via the confd class. Conftool isn't in use in beta, as beta has only a single DC, but I wasn't able to find where the special casing is.
Per Slack discussion.
Thanks for looking into it here! I'd like to note that the preferred solution is likely to differ among various users of the component. For example, Special:Block represents pages as their IDs internally, which means it needs to use something in the input list. On the other hand, in the Growth case @Michael mentioned, Growth represents pages as string titles, meaning we can process inputs such as mw:Downloads as well. Special:Block is not interested in external titles (it isn't able to process them), but Growth is (we use them in certain cases).
Low, as it will be automatically fixed with another task.
Boldly moving to sprint for @KStoller-WMF to make the final call. Feel free to move elsewhere if you think this should not be in the current sprint.
Personally, I prefer option 1, because it leaves the admin in control. If the admin wants to enter a page that does not exist yet, they should be able to do so (they can do that anyway by a manual edit, and I don't see why the UI should mask that approach). If we're afraid that the admin might do so by accident (and introduce typos), we might want to introduce a warning for that scenario, but it doesn't look like something that should be fundamentally impossible.
Fri, Jul 19
Hi @Pppery, thanks for the feedback! I understand how this could look unexpected, especially since the previous version of Community configuration does something wholly different. The reason why the fields are not disabled as they used to be is to enable non-admins to see what the other options are, in case they are hidden behind eg. a select box. This might provide information that can be then used to make a proper edit request. It is possible the confusion this behaviour brings is a bigger problem than what it aims to solve – not sure.
@KStoller-WMF @Trizek-WMF Would you mind reviewing the deployment for those wikis, once you have some time, and figure out why we ended up with this inconsistency?
According to my tests, hywwiki is the only (content) wiki where models are not available, but backend is enabled:
Thu, Jul 18
Thanks for the info, @Pppery!