On Thursday, July 25th, 2019 between the hours of 1500 and 1700 UTC we will
be performing system maintenance on the NFS servers that support Toolforge
and the CloudVPS instances that are using NFS for home, project or scratch
data.
During this maintenance window, we will be applying rolling updates that
require NFS service restarts. We are taking precautions to minimize impact,
but there may be short periods of NFS service interruption or performance
degradation.
---
Jason Hedden
Site Reliability Engineer - Wikimedia Cloud Services
Wikimedia Foundation
_______________________________________________
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
As part of routine networking and OS upgrades, I'll be emptying two
hypervisors (cloudvirt1016 and cloudvirt1017) on Monday and Tuesday, the
22nd and 23rd. This will result in downtime for many VMs as they are
copied and restarted. A complete list of affected instances follows.
I'll begin by moving the deployment-prep project at around 13:00
UTC on Monday. After that copies will proceed in roughly the order you
see below, but the timing will be hard to predict.
Please let me know if you need to schedule a more specific window
for your downtime. Better yet, if any of the listed VMs are defunct and
can simply be deleted, please do that now and save me some time!
-Andrew + the WMCS team
Affected instances (shown as <project>: <instance name>):
account-creation-assistance: accounts-appserver4
account-creation-assistance: accounts-mwoauth
automation-framework: af-puppetdb02
butterfly: butterfly-m4m2
cloudinfra: cloudinfra-db02
codereview: Krypton
codereview: Radon
commtech: commtech-2
community-labs-monitoring: clm-web-01
community-labs-monitoring: clm-worker-01
dashiki: dashiki-01
dashiki: dashiki-staging-01
deployment-prep: deployment-cache-text05
deployment-prep: deployment-changeprop
deployment-prep: deployment-chromium01
deployment-prep: deployment-chromium02
deployment-prep: deployment-cpjobqueue
deployment-prep: deployment-dumps-puppetmaster02
deployment-prep: deployment-elastic06
deployment-prep: deployment-elastic07
deployment-prep: deployment-etcd-01
deployment-prep: deployment-eventlog05
deployment-prep: deployment-imagescaler01
deployment-prep: deployment-imagescaler02
deployment-prep: deployment-ircd
deployment-prep: deployment-jobrunner03
deployment-prep: deployment-kafka-jumbo-1
deployment-prep: deployment-logstash2
deployment-prep: deployment-mediawiki-07
deployment-prep: deployment-memc06
deployment-prep: deployment-memc07
deployment-prep: deployment-mwmaint01
deployment-prep: deployment-ores01
deployment-prep: deployment-puppetdb02
deployment-prep: deployment-puppetmaster03
deployment-prep: deployment-restbase01
deployment-prep: deployment-restbase02
deployment-prep: deployment-sentry01
deployment-prep: deployment-snapshot01
deployment-prep: deployment-urldownloader02
deployment-prep: deployment-zookeeper02
design: design-research-methods
dumps: dumps-0
dwl: dwl
dwl: taxonbota
fa-wp: tofawiki02
getstarted: gitservices
getstarted: webservices
glampipe: Glampipe
hound: hound-puppet-02
integration: integration-cumin
integration: integration-r-lang-01
integration: integration-slave-docker-1040
integration: integration-slave-docker-1041
integration: integration-slave-jessie-1002
k8splay: k8s-dzahn
lizenzhinweisgenerator: lizenzhinweisgenerator
maps: maps-tiles1
maps: maps-warper3
openrefine: openrefine01
openstack: cloud-bootstrapvz-stretch
otrs: otrs-oneclickspam-test
packagist-mirror: packagist-mirror1
partnermetrics: partnermetrics-redis-01
puppet-diffs: compiler1001
qna: meza-new2
quotatest: novaadminmadethis6
reading-web-staging: readers-web-master
recommendation-api: missing-sections
recommendation-api: rec-wiki
recommendation-api: related-articles
recommendation-api: tool
security-tools: logparse01
sentry: frama-test5
sentry: frama-test6-sb
services: kask
services: kask-client
shinken: shinken-02
shiny-r: discovery-production-02
testlabs: abogott-puppetmaster
testlabs: canary1016-01
tools: tools-sgecron-01
tools: tools-sgegrid-shadow
toolsbeta: toolsbeta-sgecron-01
toolsbeta: toolsbeta-sgegrid-shadow
toolsbeta: toolsbeta-sgewebgrid-lighttpd-0901
twl: wmil
video: encoding01
video: gfg01
video: video-redis
video: videodev
videowiki: app-instance
visualeditor: dumpgrepper
webperf: disposable
wikidata-dev: wikidata-constraints
wikidata-federation: federated-commons
wikidata-federation: federated-wikidata
wikidiff2-wmde-dev: wmde-wikidiff2-jacnth
wikidocumentaries: hupu
wikidocumentaries: roope
wikidumpparse: whgi
wikifactmine: elasticsearch-20
wikifactmine: elasticsearch-21
wikifactmine: puppetmaster-01
wikilabels: wikilabels-02
wikilabels: wikilabels-experiment
wikimetrics: wikimetrics-01
wikistream: ws-web
wikitextexp: wikitextexp-base-1002
wikitextexp: wikitextexp-expt-1002
wm-bot: wm-bot-pg
wm-bot: wm-bot2
wmf-research-tools: diegoTest
wmf-research-tools: wikilabels
wpx: wpx-redirects-01
_______________________________________________
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
On Friday I'll be moving the toolforge cron server to new hardware.
During the move, any uses of the 'crontab' command will fail
gracelessly. Any cron jobs scheduled to launch during the downtime will
be skipped.
The move should take 5-10 minutes but may take as long as 30 if there
are complications.
-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
Dear all,
we’re really happy to announce the first ever Coolest Tool Award
<https://meta.wikimedia.org/wiki/Coolest_Tool_Award>!
Tools play an essential role at Wikimedia, and so do the many volunteer
developers who experiment with new ideas, develop & maintain local & global
solutions and bridge workflow gaps for the Wikimedia communities.
There are incredible many great tools out there. It’s time to celebrate
this & to make the work volunteer developers do more visible to everyone :-)
The Coolest Tool Award ceremony will take place at Wikimania, as part of
the official program:
https://wikimania.wikimedia.org/wiki/2019:Technology_outreach_%26_innovatio…
The award is organized & selected by this year's Coolest Tool Academy. The
plan is to award the greatest tools in a variety of categories: For
example: “best Commons tool” to recognize the value of a tool for a
specific project, or “best newcomer” to award the work of a fairly new
developer.
As no one can possibly know all the cool tools out there, we’re looking for
some help & inspiration: Please point us to the tools that you think are
great - out of any reason you can think of!
Please use this form:
https://docs.google.com/forms/d/1Ip5Sb_CDvgO6IN2f51V3WjkVYU9Sa-nneX5PoY0sjo…
to recommend tools by July 29, 2019.
You can nominate as many tools as you want by filling out the form multiple
times.
This survey will be conducted via a third-party service, which may subject
it to additional terms. For more information on privacy and data-handling,
see the survey privacy statement:
https://foundation.wikimedia.org/wiki/Coolest_Tool_Award_2019_Survey_Privac…
Thank you very much for your ideas & recommendation(s)!
We will continue to spread the word over the next 1-2 days, but if you get
the chance, please feel welcome to share this information with others too!
If you have any questions, please contact us at
https://meta.wikimedia.org/wiki/Coolest_Tool_Award.
Thanks :-)
Birgit, for the Coolest Tool Academy 2019
--
Birgit Müller (she/her)
Director of Technical Engagement
Wikimedia Foundation <https://wikimediafoundation.org/>
The latest Debian version, 10.0 "buster", was officially released a
few days ago[0]. Today, I've built a new Debian buster base image and
made it available in all projects.
The Stretch base image will remain available for some time to
permit compatibility with existing setups, but any new work should use
buster. If you have existing instances that were built using the buster
prelease images (or instances that you manually upgraded from an earlier
version) I encourage you to delete them and rebuild with this new base
image for the most consistent results.
-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,
The execution plan for this query [1] indicates that it will be entirely
based on existing indexes. Yet in practice, the query takes a long time to
run. Why is that?
Also, interestingly, the execution plan for this modified version [2] is
identical, but it runs almost instantaneously.
Lastly, I expect that last query to return no results (because the NOT
EXISTS condition should not be met) but it does return a row. Why is that?
Thanks!
Huji
[1]
https://tools.wmflabs.org/sql-optimizer?use=enwiki_p&sql=use+fawiki_p%3B%0D…
[2]
https://tools.wmflabs.org/sql-optimizer?use=fawiki_p&sql=select%0D%0A++p1.p…
Cross-posting from the mediawiki-api-announce(a)lists.wikimedia.org list.
---------- Forwarded message ---------
From: Brad Jorsch (Anomie) <bjorsch(a)wikimedia.org>
Date: Fri, Jun 21, 2019 at 8:30 AM
Subject: [Mediawiki-api-announce] BREAKING CHANGE: Improved timestamp support
To: <mediawiki-api-announce(a)lists.wikimedia.org>
An upgrade to the timestamp library used by MediaWiki is resulting in
two changes to the handling of timestamp inputs to the action API.
There will be no change to timestamps output by the API.
All of these changes should be deployed to Wikimedia wikis with 1.34.0-wmf.10.
Historically MediaWiki has ignored timezones in supported formats that
include timestamps, treating them as if the timezone specified were
UTC. In the future, specified timezones will be honored (and converted
to UTC).
Historically some invalid formats were accepted, such as
"2019-05-22T12:00:00.....1257" or "Wed, 22 May 2019 12:00:00 A
potato". Due to improved validation, these will no longer be accepted.
Support for ISO 8601 and other formats has also been improved. See
https://www.mediawiki.org/wiki/Timestamp for details on the formats
that will be supported.
_______________________________________________
Mediawiki-api-announce mailing list
Mediawiki-api-announce(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce
_______________________________________________
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
I files a bug report on toolforge:
https://phabricator.wikimedia.org/T226088
On Wed, Jun 19, 2019 at 9:29 AM <boghog(a)me.com> wrote:
> Thanks for your replies.
>
> I contacted the NIH to register the citation-template-filling tool and my
> e-mail address and added both as parameters to the query url (i.e.,
> “&email=my@email“ and “&tool=ciation-filling-tool") to the PubMedLite.pm
> module that citation-template-filling tool calls. They also assured me that
> “tools.wmflabs.org” has not been blocked from accessing the NIH site.
>
> I have done a few more tests:
>
> curl '
> https://eutils.ncbi.nlm.nih.gov/entrez/eutils/efetch.fcgi?db=pubmed&id=12345
> '
> curl: (6) Could not resolve host: eutils.ncbi.nlm.nih.gov
>
> does not work on the tool server, but does work on my local workstation.
> The following
>
> curl -k '
> https://eutils.ncbi.nlm.nih.gov/entrez/eutils/efetch.fcgi?db=pubmed&id=12345
> '
> curl: (6) Could not resolve host: eutils.ncbi.nlm.nih.gov
>
> also does not work. But
>
> curl -k '
> https://130.14.29.110/entrez/eutils/efetch.fcgi?db=pubmed&id=12345'
>
> works.
>
> I am not sure what to do next. Is the problem on the “tools.wmflabs.org”
> or “eutils.ncbi.nlm.nih.gov” side? Also what precisely is the problem, so
> that I can accurately describe the issue to server administrators?
>
> Thanks,
>
> Boghog
>
> On Jun 14, 2019, at 11:07 PM, Magnus Manske via Cloud <
> cloud(a)lists.wikimedia.org> wrote:
>
> FWIW, I am running a service that queries eutils.
>
> They have a rate limitation, but I do stay under that, AFAICT. Maybe
> multiple bots from the same host, together, triggered a rate limiting
> mechanism?
>
> On Fri, Jun 14, 2019 at 5:56 PM Alex Monk <krenair(a)gmail.com> wrote:
>
>> I looked at `dig eutils.ncbi.nlm.nih.gov +trace` and at `strace -f dig
>> eutils.ncbi.nlm.nih.gov +trace` - it looks to me like NIH's nameservers
>> are not willing to serve labs?
>>
>>
>> On Fri, 14 Jun 2019 at 05:59, Konrad Koehler via Cloud <
>> cloud(a)lists.wikimedia.org> wrote:
>>
>>> The following tool has been running without problem for years:
>>>
>>> https://tools.wmflabs.org/citation-template-filling/cgi-bin/index.cgi
>>>
>>> Recently the tool has started generating the following error message:
>>>
>>> Can't call method "findnodes" on an undefined value at
>>> /data/project/citation-template-filling/perl/ActivePerl-5.26/site/lib/WWW/Search/PubMedLite.pm
>>> line 117.
>>>
>>> PubMedLite.pm in turn makes a request to “'
>>> https://eutils.ncbi.nlm.nih.gov/entrez/eutils/efetch.fcgi” for data.
>>> For debugging, I queried the entrez server using an equivalent command in
>>> curl which generated the following error messages:
>>>
>>> curl '
>>> https://eutils.ncbi.nlm.nih.gov/entrez/eutils/efetch.fcgi?db=pubmed&id=1234…
>>> '
>>>
>>> curl: (6) Could not resolve host: eutils.ncbi.nlm.nih.gov
>>>
>>> I also tried replacing “eutils.ncbi.nlm.nih.gov” with its IP address:
>>>
>>> curl 'https://130.14.29.110/entrez/eutils/efetch.fcgi?db=pubmed&id=12345
>>> '
>>>
>>> curl: (51) SSL: no alternative certificate subject name matches target
>>> host name '130.14.29.110'
>>>
>>> The same curl command runs without problem on my local workstation:
>>>
>>> curl '
>>> https://eutils.ncbi.nlm.nih.gov/entrez/eutils/efetch.fcgi?db=pubmed&id=1234…
>>> ’
>>>
>>> <!DOCTYPE PubmedArticleSet PUBLIC "-//NLM//DTD PubMedArticle, 1st
>>> January 2019//EN" "
>>> https://dtd.nlm.nih.gov/ncbi/pubmed/out/pubmed_190101.dtd"> …
>>>
>>> Anyone have an idea how to fix this? Thanks,
>>>
>>> Boghog
>>> _______________________________________________
>>> Wikimedia Cloud Services mailing list
>>> Cloud(a)lists.wikimedia.org (formerly labs-l(a)lists.wikimedia.org)
>>> https://lists.wikimedia.org/mailman/listinfo/cloud
>>
>> _______________________________________________
>> Wikimedia Cloud Services mailing list
>> Cloud(a)lists.wikimedia.org (formerly labs-l(a)lists.wikimedia.org)
>> https://lists.wikimedia.org/mailman/listinfo/cloud
>
> _______________________________________________
> Wikimedia Cloud Services mailing list
> Cloud(a)lists.wikimedia.org (formerly labs-l(a)lists.wikimedia.org)
> https://lists.wikimedia.org/mailman/listinfo/cloud
>
>
>
Hello all,
Two things:
1) On Thursday June 13th at 18:00 UTC (11am Pacific) there will be an
open office hours for those of you who would like to share your thoughts
on the event; topics you'd like to see discussed there, decisions you'd
like made, etc.
It will occur using Google Meet, at this url:
https://meet.google.com/exz-zxfy-nuj
If you can't make it to this office hours, don't fret! You can always
(continue to) share your thoughts on the Phabricator task:
https://phabricator.wikimedia.org/T220212
2) REMINDER: The deadline for participant/attendee nominations is Monday
June 17th, this coming Monday. Remember, you can nominate others or
yourself. And you can fill out the form as many times as you have
nominations.
Form: https://forms.gle/CLeGFSMiEasJgEU27
FAQ: https://www.mediawiki.org/wiki/Wikimedia_Technical_Conference/2019/FAQ
This survey is conducted via a third-party service, which may make it
subject to additional terms. For more information on privacy and
data-handling, see this survey privacy statement:
https://foundation.wikimedia.org/wiki/Wikimedia_Technical_Conference_Survey…
On behalf of the Technical Conference Program Committee,
Greg
On Wed, May 29, 2019 at 04:39:37PM -0700, Greg Grossmeier wrote:
> Hello all,
>
> As you may have seen, the next Wikimedia Technical Conference[0] is
> coming up in November 2019.
>
> It will take place November 12-15th in Atlanta, GA (USA). As announced
> at the Hackathon and documented on-wiki[1] this year's event will
> focus on the topic of "Developer Productivity".
>
> Like last year, we are looking for diverse stakeholders, perspectives,
> and experiences that will help us to make informed decisions. We need
> people who can create and architect solutions, as well as those who
> will make funding and prioritization decisions for the projects.
>
> See the FAQ for (hopefully) any questions you have:
> <https://www.mediawiki.org/wiki/Wikimedia_Technical_Conference/2019/FAQ>
>
> Please fill out the survey using this link to nominate yourself or someone
> else to attend: <https://forms.gle/CLeGFSMiEasJgEU27>
>
> This survey is conducted via a third-party service, which may make it
> subject to additional terms. For more information on privacy and
> data-handling, see this survey privacy statement:
> <https://foundation.wikimedia.org/wiki/Wikimedia_Technical_Conference_Survey…>
>
> This nomination form will remain open between May 29 and June 17, 2018.
>
> If you have any questions, please post them on the event's talk page
> <https://www.mediawiki.org/wiki/Talk:Wikimedia_Technical_Conference/2019>.
>
> Thanks!
>
> Greg and the Technical Conference 2019 Program Committee
>
> [0] <https://www.mediawiki.org/wiki/Wikimedia_Technical_Conference/2019>
> [1] <https://www.mediawiki.org/wiki/Wikimedia_Technical_Conference/2019#Vision_S…>
>
> --
> Greg Grossmeier
> Release Team Manager
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| Release Team Manager A18D 1138 8E47 FAC8 1C7D |