Cloud-announce May 2020

cloud-announce@lists.wikimedia.org

3 participants
5 discussions

Toolforge: new domain toolforge.org
by Arturo Borrero Gonzalez 07 Jul '20

07 Jul '20

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

2 6

WMCS network interruptions on Thursday, 2020-05-19 and 14:00 UTC
by Andrew Bogott 21 May '20

21 May '20

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

1 2

Toolforge grid now using tesseract-ocr 4.1.1
by Arturo Borrero Gonzalez 20 May '20

20 May '20

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

1 0

Planned changes to the views on the wiki-replicas
by Brooke Storm 12 May '20

12 May '20

*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_

1 0

Horizon downtime tomorrow, 2020-05-12 14:00 UTC
by Andrew Bogott 11 May '20

11 May '20

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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

Cloud-announce May 2020