Hi!
We are happy to announce the new domain 'toolforge.org' is now ready to be
adopted by our Toolforge community.
There is a lot of information related to this change in a wikitech page we have
for this:
https://wikitech.wikimedia.org/wiki/News/Toolforge.org
The most important change you will see happening is a new domain/scheme for
Toolforge-hosted webservices:
* from https://tools.wmflabs.org/<toolname>/
* to https://<toolname>.toolforge.org/
A live example of this change can be found in our internal openstack-browser
webservice tool:
* legacy URL: https://tools.wmflabs.org/openstack-browser/
* new URL: https://openstack-browser.toolforge.org
This domain change is something we have been working on for months previous to
this announcement. Part of our work has been to ensure we have a smooth
transition from the old domain (and URL scheme) to the new canonical one.
However, we acknowledge the ride might be bumpy for some folks, due to technical
challenges or cases we didn't consider when planning this migration. Please
reach out intermediately if you find any limitation or failure anywhere related
to this change. The wikitech page also contains a section with information for
common problems.
You can check now if your webservice needs any specific change by creating a
temporal redirection to the new canonical URL:
$ webservice --canonical --backend=kubernetes start [..]
$ webservice --canonical --backend=gridengine start [..]
The --canonical switch will create a temporal redirect that you can turn on/off.
Please use this to check how your webservice behaves with the new domain/URL
scheme. If you start the webservice without --canonical, the temporal redirect
will be removed.
We aim to introduce permanent redirects for the legacy URLs on 2020-06-15. We
expect to keep serving legacy URLs forever, by means of redirections to the new
URLs. More information on the redirections can also be found in the wikitech page.
The toolforge.org domain is finally here! <3
--
Arturo Borrero Gonzalez
SRE / Wikimedia Cloud Services
Wikimedia Foundation
On Thursday we will be upgrading the network infrastructure that routes
network traffic for all cloud-vps and toolforge networking. This will
involve at least one failover between hosts, which will interrupt
existing network connections.
There should not be a prolonged network outage, but some connections
will be reset. If your tools or services are not resilient to
unexpected disconnections, you may need to manually restart services
after the updates are complete.
The changeover will happen sometime between 14:00 and 15:00 UTC this
coming Thursday. Details about this can be found at
https://phabricator.wikimedia.org/T253124
-Andrew + the WMCS team
_______________________________________________
Wikimedia Cloud Services announce mailing list
Cloud-announce(a)lists.wikimedia.org (formerly labs-announce(a)lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/cloud-announce
Hi there!
We just deployed tesseract-ocr v4.1.1 in the Toolforge grid.
The context of this update is the phabricator task T247422 [0].
Please report any issue you may find.
regards!
[0] https://phabricator.wikimedia.org/T247422
--
Arturo Borrero Gonzalez
SRE / Wikimedia Cloud Services
Wikimedia Foundation
*What is happening*: In preparation for work upstream on the production wiki databases, the Wikireplica service needs to drop some columns from the views used by Toolforge and CloudVPS users.
The columns being dropped are:
* archive.ar_text_id
* archive.ar_content_model
* archive.ar_content_format
* revision.rev_text_id
* revision.rev_content_model
* revision.rev_content_format
NOTE: revision.rev_content_format and revision.rev_text_id are only relevant when loading serialized blobs from external storage, which is
not possible from the Wiki Replicas. These columns are removed without replacement.
These columns currently contain stale data in both the replicas and the production databases. The actual data used in production was moved
entirely to the "slot" and "content" tables on 2019-11-18 (<https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/551551/>).
Information about migrating tools to the new schema is available in the description of this task: https://phabricator.wikimedia.org/T174047
Additional information about the overall project and changes can be found here:
https://www.mediawiki.org/wiki/Multi-Content_Revisions/Database_Schema
The columns will continue to exist in the the revision_compat and archive_compat tables as a stop-gap to keep a tool that relies on those fields from completely breaking while you work on updating to the new schema. These two views are expected to perform poorly because of they include joins against the content and slots tables. Please only use those if you need them and will take longer to finish refactoring your code to the new schema.
*When is this happening*: This will take time to run across the replicas and databases, possibly over the course of a few days, beginning 2020-05-25. There is a process of depooling of the servers that will take place to allow the changes to take place.
*What should I do*: Between now and the 25th of May, stop using the fields we are removing. If you don't already, make sure you use the slots and content tables instead.
Progress on this action will be tracked on this Phabricator task - https://phabricator.wikimedia.org/T252219.
--
Brooke Storm
SRE
Wikimedia Cloud Services
bstorm(a)wikimedia.org
IRC: bstorm_
_______________________________________________
Wikimedia Cloud Services announce mailing list
Cloud-announce(a)lists.wikimedia.org (formerly labs-announce(a)lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/cloud-announce
Tomorrow I'm going to upgrade several of the OpenStack control nodes to
Debian Buster. Due to version incompatibilities, Buster and Stretch
nodes can't cooperate in the same cluster, so I will need to switch
service between clusters a couple of times.
If things go really well, this will cause only brief hiccups in the
OpenStack APIs. More likely, though, things will get a bit tangled up
and Horizon will misbehave for 20-30 minutes during the transition.
The first switchover will happen between 14:00 and 15:00 tomorrow; the
second switch will follow an hour or two later.
-Andrew
_______________________________________________
Wikimedia Cloud Services announce mailing list
Cloud-announce(a)lists.wikimedia.org (formerly labs-announce(a)lists.wikimedia.org)
https://lists.wikimedia.org/mailman/listinfo/cloud-announce
Hi all,
Is it possible to store data into user tables through queries on
Wikireplica DBs? Or is it only possible by mysqldump'ing from the replica
DB and loading into the user table in a separate step?
I am thinking of aggregate data.
Thanks!
Hi all,
We have a set of database reports (on users, articles, etc.) that we used
to generate on a weekly basis.[1] Ever since the introduction of the *actor*
table,[2] many of the reports that have to do with users have become so
slow that the SQL query cannot finish within a reasonable time and is
killed. Some other reports have also become slower over time; all of these
are shown in red in [1].
One possible solution is to create a script which is scheduled to run once
a month; the script would download the latest dump of the wiki database,[3]
load it into MySQL/MariaDB, create some additional indexes that would make
our desired queries run faster, and generate the reports using this
database. A separate script can then purge the data a few days later.
We can use the current-version-only DB dumps for this purpose. I am
guessing that this process would take several hours to run (somewhere
between 2 and 10) and would require about 2 GB of storage just to download
and decompress the dump file, and some additional space on the DB side (for
data, indexes, etc.)
Out of abundance of caution, I thought I should ask for permission now,
rather than forgiveness later. Do we have a process for getting approval
for projects that require gigabytes of storage and hours of computation, or
is what I proposed not even remotely considered a "large" project, meaning
I am being overly cautious?
Please advise!
Huji
[1]
https://fa.wikipedia.org/wiki/%D9%88%DB%8C%DA%A9%DB%8C%E2%80%8C%D9%BE%D8%AF…
[2] https://phabricator.wikimedia.org/T223406
[3] https://dumps.wikimedia.org/fawiki/20200401/