Wed, Feb 12
Tue, Feb 4
Mon, Feb 3
Sun, Feb 2
Setting up the Wiki-Loves-Love bot for this year I decided to take advantage of CronJobs. I placed my example CronJob yaml definition and some notes on how to debug it in the Wikitech page.
Fri, Jan 31
yeah, my plan then is to actully go the full k8s route with prometheus-operator and such. Have not gotten around to implementing it yet.
Thu, Jan 30
Does this include updates to the toolforge prometheus instance? I wanted to funnel PAWS metrics there but it was such an old version when I tried it I gave up on getting it to work.
Tue, Jan 28
Wed, Jan 22
Seems to be missing a few edits I made a few hours ago with my bot https://xtools.wmflabs.org/autoedits-contributions/pt.wikipedia.org/ChicoBot v https://pt.wikipedia.org/wiki/Especial:Contribui%C3%A7%C3%B5es/ChicoBot
Tue, Jan 21
https://meta.wikimedia.org/w/index.php?title=Special:OAuthListConsumers/view/bf7eb39a895d1987ef9300b782fc948b&name=PAWS&publisher=&stage=-1 is the last one, probably not a lot of edits there though
How do we get the CIDs?
How to translate 0a73e346a40b07262b6e36bdba01cba4 to 429?
Jan 20 2020
Maybe add PAWS and the OAuth consumer version as the client in the meantime?
BTW, there are 5 past PAWS OAuth consumers and I will (hopefully) soon move it to a sixth one (T243200).
Jan 17 2020
This does not seem to be the underlying issue here, but PAWS will not have admin permissions. T192237
Jan 9 2020
Dec 4 2019
It has been a while, but I have a working script to add thanks links over at https://github.com/chicocvenancio/wiki_scripts/blob/gh-pages/thankLinksInWatchlist-pt.js It is localized to portuguese and doesn't quite handle genders properly right now, but if there is interest I could clean it up and add i18n for it.
I copied a few of the functions from ext.thanks and added the links manually to the dom.
Nov 4 2019
Sure, makes sense.
@bd808 I don't think these are duplicates. As I understand T174469 is a backend problem that makes accounts that are not attached to Wikitech not have a way to reset passwords. This is more of a feature request to have some indication in Striker of how to reset passwords.
Adding a link to https://wikitech.wikimedia.org/wiki/Special:PasswordReset might be good enough to avoid confusion.
Nov 2 2019
Oct 31 2019
That was it, thanks @Phamhi.
Oct 29 2019
having a separate OAuth flow
This is the part that is complicated in my view, specially doing this securely and with a good UX in PAWS.
Oct 24 2019
Hey @Tgr, I'm not sure setting up automatic OAuth with the beta cluster is straightforward. The reason we can do it with the production wikis is we authenticate the user with them and just use the same OAuth tokens to pass to Pywikibot. As I understand it, there is no way to authenticate with production wikis and use that session with the beta-cluster, so we would need to setup a different authenticator for PAWS specifically for the beta-cluster, this is not impossible but I fear it is a significant amount of development and may create confusion for normal users.
Thanks for creating this ticket. The pod was stuck in terminating state in the node tools-paws-worker-1007 for the past couple of days. I removed it with kubectl -n prod delete pod jupyter--43riscod --force grace-period=0 perhaps someone with root access should check docker to see if/why the container is still running.
Oct 22 2019
@Dominicbm I agree this is a great improvement for PAWS. Unfortunately I do not have the bandwidth to develop this for the foreseeable future and no other volunteers have stepped up.
Oct 2 2019
Sep 9 2019
Aug 30 2019
Aug 15 2019
Aug 13 2019
Aug 12 2019
Aug 8 2019
I've tested with and without the UserAgent, it sometimes works when defaulting to the SPARQLWrapper agent, but without looking at server logs and configuration I don't have much clue on why this is happening. Perhaps someone can investigate and tell us.
Indeed setting a different agent works. https://paws-public.wmflabs.org/paws-public/User:chicocvenancio/T230135.ipynb
This seems relevant https://github.com/RDFLib/sparqlwrapper/issues/139
BTW you can use a ! to run commands directly from the notebooks. IE use !pip install sparqlwrapper instead of using the terminal every server start. see https://paws-public.wmflabs.org/paws-public/User:chicocvenancio/T230135.ipynb
This seems to be an HTTP response from https://query.wikidata.org/
Jul 16 2019
@Mohinem how are you trying to login? There is no login required for Wikimedia wikis.
Jul 12 2019
It seems this is an artifact of the packages installed in the singleuser image clashing in some way. I don't know what packages are the source of this error and have not had the time to investigate this more closely.
Jun 19 2019
In short, currently, don't.
@bd808 should we ask for a VPS project to have a subdomain we can verify ourselves or is there a way to verify tools.wmflabs.org itself?
I would think of having a simple proxy to Toolforge with nginx if a project is indeed necessary.
May 21 2019
May 19 2019
Sorry, this was in PAWS, so maybe something we're doing with Auth there is messing this up.
May 18 2019
Finally tracked this being due to helm attempting to talk directly to k8s with the pod's serviceAccount instead of the Tiller one.
It works again.
Where are the project rooms?
The project rooms are on the 4th floor.
May 17 2019
I'm trying to fix this task in Wikimedia-Hackathon-2019. Hopefully we can start accepting and merging PRs for PAWS image changes soon.
May 13 2019
Apr 26 2019
Thanks @bd808. This can be closed then.
cloud-services-team Could someone check the Icinga settings for the PAWS page? Just making sure it includes the /paws url path before closing this?
I'm slightly afraid this will lead to more confused users, but I'll change this and see if any complaints pour in.
I would be interest in talking to the pwb devs there. Not sure if there is enough audience for a session, but I'm interested in meeting and talking to you guys if there is not a session.
Apr 22 2019
Apr 18 2019
Apr 17 2019
Apr 16 2019
That is T192237. Yeah, we could have multiple Wikimedia oAuth consumers, one without admin permissions to limit attack surface and one with them to allow users to use admin powers. However a lack of oAuth v2 support in mediawiki (T125337) means it would take a lot of PAWS-specific development to get any oAuth done in a safe way(T120469). While I mostly feel confortable leaving that avenue open as it stands, opening the possibility of admin actions through PAWS means a step too far in my view. One year and a day ago I created T192237, since no one has commented there for us to enable admin actions despite the lack of security inherent in the current setup I am taking this as a very niche feature that hopefully can be taken care of once Mediawiki allows oAuth v2.
Apr 11 2019
@Bstorm do we have a timeline on the NFS side of things? I would want to have an updated version of PAWS (hopefully capacity tested) before the Wikimedia-Hackathon-2019 next month. If it is not viable to do this move before then I would do the upgrades in place (though I'll then need root time to update k8s in tools).
@Harej Should we turn this to a feature request make PAWS add oAuth credentials to some requests to Wikimedia projects or close it?