- https://meta.wikimedia.org/wiki/User:Taavi
- https://meta.wikimedia.org/wiki/User:Taavi-WMF
- Profile picture: https://w.wiki/A3GY, CC BY-SA 4.0, Robert Sim
User Details
- User Since
- Feb 24 2019, 3:58 PM (354 w, 6 d)
- Roles
- Administrator
- Availability
- Available
- IRC Nick
- taavi
- LDAP User
- Majavah
- MediaWiki User
- Taavi [ Global Accounts ]
Yesterday
Seems reasonable to me. We could even just add people to Trusted-Contributors after their Toolforge access request has been approved, instead of only adding those who end up creating a project.
Fri, Dec 12
Seems like your tool is running out of memory:
taavi@tools-bastion-14:~ $ k describe -n tool-checkwiki pod checkwiki-59666598d4-cx57c Name: checkwiki-59666598d4-cx57c Namespace: tool-checkwiki [cut] Last State: Terminated Reason: OOMKilled Exit Code: 137 Started: Fri, 12 Dec 2025 17:43:13 +0000 Finished: Fri, 12 Dec 2025 17:44:35 +0000 [...]
Thu, Dec 11
Well, derp, this indeed requests a new project in addition to the column management permissions that Trusted-Contributors gives. Which leads me to: Why a subproject? (Since you can't have a specific task tagged in both a parent project and subproject at the same time, there's not much more you can do with a subproject in this case compared to just playing with the main board directly.)
Added you to Trusted-Contributors
Wed, Dec 10
Grepping for the request ID shows this:
Dec 10 18:38:16 registry2005 docker-registry[608]: time="2025-12-10T18:38:16.115838953Z" level=error msg="unknown error completing upload: timeout expired while waiting for segments of /docker/registry/v2/repositories/restricted/mediawiki-multiversion/_uploads/b01bff22-794f-4341-bbd9-41d53187ffd1/data to show up" go.version=go1.19.8 http.request.host=docker-registry.discovery.wmnet http.request.id=52d055ca-f623-4185-9e0e-d69a2e83f977 http.request.method=PUT http.request.remoteaddr=10.192.32.7 http.request.uri="/v2/restricted/mediawiki-multiversion/blobs/uploads/b01bff22-794f-4341-bbd9-41d53187ffd1?_state=[redacted]&digest=[redacted]" http.request.useragent="docker/20.10.5+dfsg1 go/go1.15.15 git-commit/363e9a8 kernel/5.10.0-36-amd64 os/linux arch/amd64 UpstreamClient(Docker-Client/20.10.5+dfsg1 \\(linux\\))" vars.name=restricted/mediawiki-multiversion vars.uuid=b01bff22-794f-4341-bbd9-41d53187ffd1
Nothing immediately obvious in the registry logs:
Dec 10 18:38:16 registry2005 docker-registry[608]: time="2025-12-10T18:38:16.115983796Z" level=error msg="error canceling upload after error: already committed" go.version=go1.19.8 http.request.host=docker-registry.discovery.wmnet http.request.id=52d055ca-f623-4185-9e0e-d69a2e83f977 http.request.method=PUT http.request.remoteaddr=10.192.32.7 http.request.uri="/v2/restricted/mediawiki-multiversion/blobs/uploads/b01bff22-794f-4341-bbd9-41d53187ffd1?_state=[redacted]&digest=[redacted]" http.request.useragent="docker/20.10.5+dfsg1 go/go1.15.15 git-commit/363e9a8 kernel/5.10.0-36-amd64 os/linux arch/amd64 UpstreamClient(Docker-Client/20.10.5+dfsg1 \\(linux\\))" vars.name=restricted/mediawiki-multiversion vars.uuid=b01bff22-794f-4341-bbd9-41d53187ffd1 Dec 10 18:38:16 registry2005 docker-registry[608]: time="2025-12-10T18:38:16.145477553Z" level=error msg="response completed with error" err.code=unknown err.detail="timeout expired while waiting for segments of /docker/registry/v2/repositories/restricted/mediawiki-multiversion/_uploads/b01bff22-794f-4341-bbd9-41d53187ffd1/data to show up" err.message="unknown error" go.version=go1.19.8 http.request.host=docker-registry.discovery.wmnet http.request.id=52d055ca-f623-4185-9e0e-d69a2e83f977 http.request.method=PUT http.request.remoteaddr=10.192.32.7 http.request.uri="/v2/restricted/mediawiki-multiversion/blobs/uploads/b01bff22-794f-4341-bbd9-41d53187ffd1?_state=[redacted]&digest=[redacted]" http.request.useragent="docker/20.10.5+dfsg1 go/go1.15.15 git-commit/363e9a8 kernel/5.10.0-36-amd64 os/linux arch/amd64 UpstreamClient(Docker-Client/20.10.5+dfsg1 \\(linux\\))" http.response.contenttype="application/json; charset=utf-8" http.response.duration=13.175337905s http.response.status=500 http.response.written=70 vars.name=restricted/mediawiki-multiversion vars.uuid=b01bff22-794f-4341-bbd9-41d53187ffd1 Dec 10 18:38:16 registry2005 docker-registry[608]: 127.0.0.1 - - [10/Dec/2025:18:38:02 +0000] "PUT /v2/restricted/mediawiki-multiversion/blobs/uploads/b01bff22-794f-4341-bbd9-41d53187ffd1?_state=[redacted]&digest=[redacted] HTTP/1.1" 500 70 "" "docker/20.10.5+dfsg1 go/go1.15.15 git-commit/363e9a8 kernel/5.10.0-36-amd64 os/linux arch/amd64 UpstreamClient(Docker-Client/20.10.5+dfsg1 \\(linux\\))"
Tue, Dec 9
Please provide the full HTTP response body, which either details why the request is blocked or contains an internal identifier for us to locate the relevant WAF rule.
Mon, Dec 8
Toolforge access can be requested via https://toolsadmin.wikimedia.org/.
Sat, Dec 6
Fri, Dec 5
Declining to reflect reality.
We've renamed a lot of things over the years.
Yes, this is https://lists.wikimedia.org/hyperkitty/list/cloud-announce@lists.wikimedia.org/thread/WDYB4XJ6GCQYVD4JUEOD2TJKFGSQFXFH/ and I forgot to close the task.
Thu, Dec 4
@ATitkov: Ping? Any news here?
Wed, Dec 3
As far as I can tell this is MW serving a blank page:
taavi@deploy2002 ~ $ curl -v --connect-to ::mw-web.discovery.wmnet:4450 "https://www.mediawiki.org/w/index.php?title=User:DannyS712/sandbox&oldid=6207359&action=raw" * Uses proxy env variable no_proxy == 'wikipedia.org,wikimedia.org,wikibooks.org,wikinews.org,wikiquote.org,wikisource.org,wikiversity.org,wikivoyage.org,wikidata.org,wikiworkshop.org,wikifunctions.org,wiktionary.org,mediawiki.org,wmfusercontent.org,w.wiki,wikimediacloud.org,wmnet,127.0.0.1,::1' * Connecting to hostname: mw-web.discovery.wmnet * Connecting to port: 4450 * Trying 10.2.1.75:4450... * Connected to mw-web.discovery.wmnet (10.2.1.75) port 4450 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server did not agree to a protocol * Server certificate: * subject: CN=mediawiki-main-tls-proxy-certs * start date: Nov 19 20:56:00 2025 GMT * expire date: Dec 17 20:56:00 2025 GMT * subjectAltName: host "www.mediawiki.org" matched cert's "*.mediawiki.org" * issuer: C=US; L=San Francisco; O=Wikimedia Foundation, Inc; OU=SRE Foundations; CN=discovery * SSL certificate verify ok. > GET /w/index.php?title=User:DannyS712/sandbox&oldid=6207359&action=raw HTTP/1.1 > Host: www.mediawiki.org > User-Agent: curl/7.74.0 > Accept: */* > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * old SSL session ID is stale, removing * Mark bundle as not supporting multiuse < HTTP/1.1 404 Not Found < date: Wed, 03 Dec 2025 18:40:46 GMT < server: mw-web.codfw.main-78dd885bd6-rdrgr < x-powered-by: PHP/8.3.26 < x-content-type-options: nosniff < content-security-policy: default-src 'self'; script-src 'none'; object-src 'none' < vary: Accept-Encoding,X-Subdomain,Cookie,Authorization < cache-control: public, s-maxage=0, max-age=1209600 < traceparent: 00-24245b4fcba3a33764d2c01fa3ba782f-c9d7b65c49cacf2c-00 < x-request-id: e57e9104-f0fa-4b7d-b387-d1a2f2d54f3f < last-modified: Tue, 21 Nov 2023 02:58:50 GMT < backend-timing: D=51247 t=1764787246163783 < content-length: 0 < content-type: text/x-wiki; charset=UTF-8 < x-envoy-upstream-service-time: 51 < * Connection #0 to host mw-web.discovery.wmnet left intact
(note the content-type: text/x-wiki; charset=UTF-8 header!)
After merging the default settigns patch above I went through all grafana.wmcloud.org dashboards and changed the few non-UTC ones to use the default (which is now UTC). There were some in browser time, and a few ones hardcoded to CET for some reason(?).
Sure, done at https://tools-static.wmflabs.org/admin/meta/worker-ips.json and documented at the same place.
Ok, we now publish https://meta.wmcloud.org/cloudvps-ips-all.json (which is now documented at https://wikitech.wikimedia.org/wiki/Help:Cloud_VPS_IP_space#Machine-readable_data). I can't quite tell from the comments here - would a similar file for the Toolforge workers be helpful as well?
Tue, Dec 2
Your credentials will be usable in about half an hour when Puppet runs on the full Elastic cluster.
I don't think we currently have any places outside of https://wikitech.wikimedia.org/wiki/Help:Cloud_VPS_IP_space that publish our IP space. Would it be helpful if we published the same information in some machine-readable format?