User Details
- User Since
- Mar 29 2015, 4:07 PM (416 w, 6 d)
- Availability
- Available
- LDAP User
- Tarrow
- MediaWiki User
- T Arrow (WMDE) [ Global Accounts ]
Wed, Mar 15
AFAIK this shouldn't affect us and can easily be ruled out by testing the build
Doesn't look like we load any extensions using composer to me: (https://github.com/wbstack/mediawiki/blob/main/composer.json)
Tue, Mar 14
See no reason why this can't be picked up by someone who has capacity to do so hence back in todo (after I very roughly checked the thing worked locally)
Right looks good to me. I tried some classic things:
- making entities using the ui
- editing them
- seeing this reflected in the query service
- seeing this reflected in elasticsearch
- creating items using quickstatements
Fixed with https://github.com/wbstack/mediawiki/pull/321/commits/271a4d9c97b00bfb2efdaeef4704cf0cf1fa6554 ;
It would be nice to have some rough end to end tests that would have confirm things like quickstatements work in addition to:
- some integration tests for these internal private api call
- some unit testing of our additional custom code
- some static analysis of our extra custom code
[error] [exception] [c742d2d74aecbe0c0b0cf9e8] /w/api.php?action=wbstackPlatformOauthGet&format=json Error: Class 'MediaWiki\Extensions\OAuth\Backend\Utils' not found
#0 /var/www/html/w/wbstack/src/Internal/ApiWbStackOauthGet.php(27): WBStack\Internal\WbStackPlatformReservedUser::getOAuthConsumer(string, string)
#1 /var/www/html/w/includes/api/ApiMain.php(1892): WBStack\Internal\ApiWbStackOauthGet->execute()
#2 /var/www/html/w/includes/api/ApiMain.php(870): ApiMain->executeAction()
#3 /var/www/html/w/includes/api/ApiMain.php(841): ApiMain->executeActionWithErrorHandling()
#4 /var/www/html/w/api.php(94): ApiMain->execute()
#5 /var/www/html/w/api.php(49): wfApiMain()
#6 {main}
[error] [exception-json] {"id":"c742d2d74aecbe0c0b0cf9e8","type":"Error","file":"/var/www/html/w/wbstack/src/Internal/WbStackPlatformReservedUser.php","line":119,"message":"Class 'MediaWiki\\Extensions\\OAuth\\Backend\\Utils' not found
","code":0,"url":"/w/api.php?action=wbstackPlatformOauthGet&format=json","caught_by":"entrypoint","backtrace":[{"file":"/var/www/html/w/wbstack/src/Internal/ApiWbStackOauthGet.php","line":27,"function":"getOAuthConsumer","class":"WBSta
ck\\Internal\\WbStackPlatformReservedUser","type":"::","args":["string","string"]},{"file":"/var/www/html/w/includes/api/ApiMain.php","line":1892,"function":"execute","class":"WBStack\\Internal\\ApiWbStackOauthGet","type":"->","args":[
]},{"file":"/var/www/html/w/includes/api/ApiMain.php","line":870,"function":"executeAction","class":"ApiMain","type":"->","args":[]},{"file":"/var/www/html/w/includes/api/ApiMain.php","line":841,"function":"executeActionWithErrorHandli
ng","class":"ApiMain","type":"->","args":[]},{"file":"/var/www/html/w/api.php","line":94,"function":"execute","class":"ApiMain","type":"->","args":[]},{"file":"/var/www/html/w/api.php","line":49,"function":"wfApiMain","args":[]}]}
172.17.0.1 - - [14/Mar/2023:12:14:40 +0000] "POST /w/api.php?action=wbstackPlatformOauthGet&format=json HTTP/1.1" 200 1335 "-" "WBStack - Quickstatements - WbstackMagnusOauth::parse_ini_file"Mon, Mar 13
Fri, Mar 10
Thu, Mar 9
We're now awaiting contact from the Wiki owner to confirm which users (if any) that currently exist need to be promoted to Bureaucrat
"[error] [exception] [c0e209e21f487eb158cbed56] /w/api.php?action=wbstackInit&format=json InvalidArgumentException: UserGroupManager::addUserToGroup() needs a positive user ID. Perhaps addUserToGroup() was called before the user was added to the database." Looks like the issue. Presumably due to something like an invalid username? ( see: https://github.com/wbstack/mediawiki/blob/main/dist-persist/wbstack/src/Internal/ApiWbStackInit.php#L50 for where we should have caught this error a little earlier and https://github.com/wbstack/api/blob/main/app/Http/Controllers/WikiController.php#L42 for where we should have caught this even earlier )
Looks like there may be another possible instance of this: T331390
Cool! So you found an exception to the issue: local URLs work fine.
Tue, Mar 7
chatted to @Evelien_WMDE in the daily; if it works let's just go ahead and deploy this
Thu, Mar 2
Some working notes from Andrew on this ticket: https://docs.google.com/document/d/1f8VZBn-zW_ozmKTUnRdCOVFLj7_me_gcEEkOr_-yslI/edit#
At least as per https://gerrit.wikimedia.org/r/plugins/gitiles/search/highlighter/+/refs/heads/master/pom.xml#22 / https://gerrit.wikimedia.org/r/plugins/gitiles/search/extra/+/refs/heads/master/pom.xml#22 it looks like the plugins are Apache so probably no licensing issues
Feb 23 2023
https://www.wikidata.org/wiki/Help:QuickStatements#Edit_groups
EditGroups is another external tool, not part of QuickStatements. Currently it works on Wikidata, and there is also an instance for Commons. On other Wikibase instances, it may be unavailable.
For a place to start looking maybe try this fairly complex block? https://github.com/wbstack/cradle/blob/main/public_html/vue.js#L31 I'm afraid at a glance understanding what needs changing here isn't trivial to me.
At first glance it appears that the issue is that a WikiData object is made that is hardcoded to use the wikidata apis.
Feb 22 2023
Feb 21 2023
I've followed up with the user and given her some credentials for a test account I have confirmed can log in. Waiting to hear if that works
I've started a job to resolve this backlog for this specific wikibase:
WBS_DOMAIN="riga-literata.wikibase.cloud" ./runAllMWJobs.sh job.batch/run-all-mw-jobs-4f7qf created
In terms of the issues for Riga literata it looks like there are a fair few jobs in the queue for this wiki. Right now >1000.
kubectl exec -it deployment/mediawiki-137-fp-app-web -- bash -c "WBS_DOMAIN='riga-literata.wikibase.cloud' php w/maintenance/showJobs.php" 1124
Specifically the attempt last night was on her phone at "20 Feb 2023 17:54:55" (I assume UTC)
I've followed up with the user and given her some credentials for a test account I have confirmed can log in. Waiting to hear if that works
Lucy and I had a further chat yesterday to try and debug this. We had a look at her browser console to see if there was anything of use there. Snippets are as follows:
Feb 17 2023
Feb 16 2023
n.b. we checked and as per (https://github.com/wbstack/api/blob/1922c91cd29b653ffe873f339f8b8aa819841ae7/app/Http/Controllers/WikiController.php#L98) this setting is set when a user creates a wiki not at the "pre-cooking" stage so we won't need to try and clear up wikidatabases that are created but unassigned
Feb 14 2023
Feb 13 2023
All seems to have worked successfully:
[elasticsearch@elasticsearch-master-0 ~]$ df -h Filesystem Size Used Avail Use% Mounted on overlay 28G 8.1G 20G 30% / tmpfs 64M 0 64M 0% /dev tmpfs 63G 0 63G 0% /sys/fs/cgroup /dev/sda1 28G 8.1G 20G 30% /etc/hosts shm 64M 0 64M 0% /dev/shm /dev/sde 9.8G 2.9G 7.0G 29% /usr/share/elasticsearch/data tmpfs 117G 12K 117G 1% /run/secrets/kubernetes.io/serviceaccount tmpfs 63G 0 63G 0% /proc/acpi tmpfs 63G 0 63G 0% /proc/scsi tmpfs 63G 0 63G 0% /sys/firmware
Gonna roll exactly the same steps for production.
- Merge PR
- Delete STS
- Deploy PR
- Run 3x patch commands
This seems to have worked "fine" on staging.
[elasticsearch@elasticsearch-master-0 ~]$ df -h Filesystem Size Used Avail Use% Mounted on overlay 28G 8.6G 19G 32% / tmpfs 64M 0 64M 0% /dev tmpfs 7.9G 0 7.9G 0% /sys/fs/cgroup /dev/sda1 28G 8.6G 19G 32% /etc/hosts shm 64M 0 64M 0% /dev/shm /dev/sdc 11G 1008M 9.8G 10% /usr/share/elasticsearch/data tmpfs 13G 12K 13G 1% /run/secrets/kubernetes.io/serviceaccount tmpfs 7.9G 0 7.9G 0% /proc/acpi tmpfs 7.9G 0 7.9G 0% /proc/scsi tmpfs 7.9G 0 7.9G 0% /sys/firmware
applied cleanly then ran
kubectl patch pvc elasticsearch-master-elasticsearch-master-0 -p '{"spec":{"resources":{"requests": {"storage":"10.1Gi"}}}}'
and repeated for 1 and 2
Merged https://github.com/wmde/wbaas-deploy/pull/728
ran k delete sts elasticsearch-master --cascade=false
running make apply-staging
currently doing them in batches of 5 and monitoring the logs/error dashboards
Feb 10 2023
Yesterday we tried a number of attempts to get a feeling for what was going on with the slow elasticsearch start up by making a number of changes on staging.