On Thu, Dec 30, 2021, 10:27 AM Samuel Klein <meta.sj(a)gmail.com> wrote:
> Separate thread. I'm not sure which list is appropriate.
> *... but not all the way to sentience
> <https://en.wikipedia.org/wiki/The_Uplift_War>.*
>
> The annual community wishlist survey (implemented by a small team,
> possibly in isolation?) may not be the mechanism for prioritizing large
> changes, but the latter also deserves a community-curated priority queue.
> To complement the staff-maintained priorities in phab ~
>
> For core challenges (like Commons stability and capacity), I'd be
> surprised if the bottleneck were people or budget.
>
Currently there are zero people and no budget for multimedia, aside from
whatever work I and others manage to get done here there. And I'm afraid I
don't scale.
It's Wikimedia Foundation's job to assign budget and people here. I've been
hoping for years that this will happen, and continue to hope.
-- brion
We do need a shared understanding of what issues are most important and
> most urgent, and how to solve them. For instance, a way to turn Amir's
> recent email about the problem (and related phab tickets) into a family of
> persistent, implementable specs and proposals and their articulated
> obstacles.
>
> An issue tracker like phab is good for tracking the progress and
> dependencies of agreed-upon tasks, but weak for discussing what is
> important, what we know about it, how to address it. And weak for
> discussing ecosystem-design issues that are important and need persistent
> updating but don't have a simple checklist of steps.
>
> So where is the best current place to discuss scaling Commons, and all
> that entails? Some examples from recent discussions (most from the wm-l
> thread below):
> - *Uploads*: Support for large file uploads / Keeping bulk upload tools
> online
> - *Video*: Debugging + rolling out the videojs
> <https://phabricator.wikimedia.org/T248418> player
> - *Formats*: Adding support for CML
> <https://phabricator.wikimedia.org/T18491> and dozens of other
> <https://phabricator.wikimedia.org/T297514> common high-demand file
> formats
> - *Thumbs*: Updating thumbor <https://phabricator.wikimedia.org/T216815>
> and librsvg <https://phabricator.wikimedia.org/T193352>
> - *Search*: WCQS still <https://phabricator.wikimedia.org/T297454> down
> <https://phabricator.wikimedia.org/T297454>, noauth option
> <https://phabricator.wikimedia.org/T297995> wanted for tools
> - *General*: Finish implementing redesign
> <https://phabricator.wikimedia.org/T28741> of the image table
>
> SJ
>
> On Wed, Dec 29, 2021 at 6:26 AM Amir Sarabadani <ladsgroup(a)gmail.com>
> wrote:
>
>> I'm not debating your note. It is very valid that we lack proper support
>> for multimedia stack. I myself wrote a detailed rant on how broken it is
>> [1] but three notes:
>> - Fixing something like this takes time, you need to assign the budget
>> for it (which means it has to be done during the annual planning) and if
>> gets approved, you need to start it with the fiscal year (meaning July
>> 2022) and then hire (meaning, write JD, do recruitment, interview lots of
>> people, get them hired) which can take from several months to years. Once
>> they are hired, you need to onboard them and let them learn about our
>> technical infrastructure which takes at least two good months. Software
>> engineering is not magic, it takes time, blood and sweat. [2]
>> - Making another team focus on multimedia requires changes in planning,
>> budget, OKR, etc. etc. Are we sure moving the focus of teams is a good
>> idea? Most teams are already focusing on vital parts of wikimedia and
>> changing the focus will turn this into a whack-a-mole game where we fix
>> multimedia but now we have critical issues in security or performance.
>> - Voting Wishlist survey is a good band-aid in the meantime. To at least
>> address the worst parts for now.
>>
>> I don't understand your point tbh, either you think it's a good idea to
>> make requests for improvements in multimedia in the wishlist survey or you
>> think it's not. If you think it's not, then it's offtopic to this thread.
>>
>> [1]
>> https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org…
>> [2] There is a classic book in this topic called "The Mythical Man-month"
>>
>> On Wed, Dec 29, 2021 at 11:41 AM Gnangarra <gnangarra(a)gmail.com> wrote:
>>
>>> we have to vote for regular maintenance and support for
>>> essential functions like uploading files which is the core mission of
>>> Wikimedia Commons
>>>
>> _______________________________________________
> Commons-l mailing list -- commons-l(a)lists.wikimedia.org
> To unsubscribe send an email to commons-l-leave(a)lists.wikimedia.org
>
Hello,
As of today, all requests to several special pages (and their API
counterparts) are subject to a maximum database query execution time of 30
seconds. These special pages are: RecentChanges, Watchlist, Contributions,
and Log. This limit has already been in place for one third of all requests
accessing these page types since December 16th.
This threshold is based on a sampling of half a million requests done to
these special pages by users (excluding crawlers) in three largest wikis
(English Wikipedia, Wikidata and Wikimedia Commons). Out of 500,000
requests only 64 were above thirty seconds and 38 (out of that 64) were
above 60s. This meant that while the database returned the result of the
query in those cases, due to the 60 second limit of the webservice workers,
no results were shown to the user. Our logs show that we have around 1000
requests taking more than thirty seconds (in database query time) per day
so the ratio is extremely small (We get around 10 billion requests per day).
Putting things in context, these queries, while being only 0.01% of the
total number of requests to those special pages, were responsible for 2.9%
of the load. In a few scenarios where such queries appeared at a higher
volume, they were a contributing factor in outages that made one or more
Wikimedia projects unavailable. If left as-is the current configuration is
a potential DDoS vector (and likely was weaponized as one).
Even though ~1000 requests a day is not much, I understand that it is an
inconvenience and it might break useful workflows for some people (for
example patrollers). Query timeout doesn’t mean your request is bad, it
means our database schemas need improvements. We are aware of some of these
needed improvements and we are working on it but migrating terabytes of
data that needs to be replicated to twenty different servers while serving
millions of queries per second is not easy and will take time.
In the meantime, if this is breaking your workflow, please use
https://quarry.wmcloud.org or build a tool in Toolforge (it has access to
database replicas with a much higher timeout) to accommodate. For more
information, see:
https://wikitech.wikimedia.org/wiki/Help:Toolforge/Database
If you need advice on writing the queries. Feel free to create a ticket
with the “Data-Persistence (Consultation)” tag and we would be happy to
help.
For similar reasons the DynamicPageList extension has had a query limit of
10 seconds (due to its history of causing major issues
<https://phabricator.wikimedia.org/T287380>) since December 16.
Unfortunately, this doesn’t mean it’s safe to enable DPL on more wikis.
For more information, you can take a look at the ticket:
https://phabricator.wikimedia.org/T297708
Thank you
--
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation <https://wikimediafoundation.org/>
I am pleased to announce that Wikimedia Enterprise's HTML dumps [1] for
October 17-18th are available for public download; see
https://dumps.wikimedia.org/other/enterprise_html/ for more information. We
expect to make updated versions of these files available around the 1st/2nd
of the month and the 20th/21st of the month, following the cadence of the
standard SQL/XML dumps.
This is still an experimental service, so there may be hiccups from time to
time. Please be patient and report issues as you find them. Thanks!
Ariel "Dumps Wrangler" Glenn
[1] See https://www.mediawiki.org/wiki/Wikimedia_Enterprise for much more
about Wikimedia Enterprise and its API.
Hello cloud-vps users,
There are still about 84 unclaimed projects at
https://wikitech.wikimedia.org/wiki/News/Cloud_VPS_2021_Purge
Please take a moment to look at that page and mark projects that you are
using.
Unclaimed projects will be in danger of shutdown on February 1st, 2022.
Thank you to those of you who have already acted on this.
Thank you!
- Komla
-------- Forwarded Message --------
Subject: Cloud VPS users, please claim your projects (and, introducing
Komla)
Date: Thu, 2 Dec 2021 14:42:08 -0600
From: Andrew Bogott <abogott(a)wikimedia.org> <abogott(a)wikimedia.org>
Reply-To: abogott(a)wikimedia.org
Organization: The Wikimedia Foundation
To: Cloud-announce(a)lists.wikimedia.org
CC: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
<wikitech-l(a)lists.wikimedia.org>
Hello cloud-vps users!
It's time for our annual cleanup of unused projects and resources. Our new
developer advocate Komla Sapaty will be guiding this process; please
respond promptly to his emails and do your best to make him feel welcome!
Every year or so the Cloud Services team tries to identify and clean up
unused projects and VMs. We do this via an opt-in process: anyone can mark
a project as 'in use,' and that project will be preserved for another year.
I've created a wiki page that lists all existing projects, here:
https://wikitech.wikimedia.org/wiki/News/Cloud_VPS_2021_Purge
If you are a VPS user, please visit that page and mark any projects that
you use as {{Used}}. Note that it's not necessary for you to be a project
admin to mark something -- if you know that you're currently using a
resource and want to keep using it, go ahead and mark it accordingly. If
you /are/ a project admin, please take a moment to mark which VMs are or
aren't used in your projects.
When February arrives, I will shut down and begin the process of reclaiming
resources from unused projects.
If you think you use a VPS project but aren't sure which, I encourage you
to poke around on https://tools.wmflabs.org/openstack-browser/ to see what
looks familiar. Worst case, just email cloud(a)lists.wikimedia.org with a
description of your use case and we'll sort it out there.
Exclusive toolforge users are free to ignore this email and future related
things.
Thank you!
-Andrew and the WMCS team
Hi Community Metrics team,
This is your automatic monthly Phabricator statistics mail.
Accounts created in (2021-12): 263
Active Maniphest users (any activity) in (2021-12): 959
Task authors in (2021-12): 458
Users who have closed tasks in (2021-12): 254
Projects which had at least one task moved from one column to another on
their workboard in (2021-12): 258
Tasks created in (2021-12): 1617
Tasks closed in (2021-12): 1325
Open and stalled tasks in total: 49056
* Only open tasks in total: 48154
* Only stalled tasks in total: 902
Median age in days of open tasks by priority:
Unbreak now: 24
Needs Triage: 726
High: 1033
Normal: 1601
Low: 2210
Lowest: 2290
(How long tasks have been open, not how long they have had that priority)
Active Differential users (any activity) in (2021-12): 3
To see the names of the most active task authors:
* Go to https://wikimedia.biterg.io/
* Choose "Phabricator > Overview" from the top bar
* Adjust the time frame in the upper right corner to your needs
* See the author names in the "Submitters" panel
TODO: Numbers which refer to closed tasks might not be correct, as
described in https://phabricator.wikimedia.org/T1003 .
Yours sincerely,
Fab Rick Aytor
(via community_metrics.sh on phab1001 at Sat 01 Jan 2022 12:00:28 AM UTC)