Should we include on-wiki user JavaScript/Gadgets in that? Basically,
everything that is not supplied by WMF directly? I feel there is a strong
overlap; the fact that it is loaded on the actual wiki notwithstanding.
On Wed, Mar 28, 2018 at 6:26 AM David Richfield
wrote:
> That seems like a good
I have emptied wdq-mm, feel free to delete the project!
On Tue, Sep 18, 2018 at 1:24 AM Chico Venancio
wrote:
> Both domains point to wm-bot2.wm-bot.eqiad.wmflabs that is hosted in
> the wm-bot project. [1] The bots project is not involved here and deleting
> or keeping it will not impact this s
Thanks, all looking good!
On Tue, Feb 19, 2019 at 2:57 PM Goran Milovanovic <
goran.milovanovic_...@wikimedia.de> wrote:
> Thank you guys, all my tools.labsdb dependent dashboards are running
> smoothly again. Thanks for the hard work!
>
> Best,
> Goran
>
>
> On Tue, Feb 19, 2019, 15:52 Arthur Sm
Same here
On Mon, Mar 11, 2019 at 3:14 PM Maximilian Doerr
wrote:
> I’m getting millions of these as well.
>
> Cyberpower678
> English Wikipedia Account Creation Team
> English Wikipedia Administrator
> Global User Renamer
>
> On Mar 11, 2019, at 11:11, Martin Urbanec
> wrote:
>
>
>
> -
It might help to mail tool users about their tools that have files with
>45GB, say, once a week or month.
Cheers,
Magnus
On Wed, Mar 13, 2019 at 7:25 PM Brooke Storm wrote:
> Due to repeated recent outages in the past 30 days and a long history of
> previous outages due to log files filling up
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 wrote:
> I looked at `dig eutils.ncbi.nlm.nih.gov +tr
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
>
I switched a few "big ones" successfully, but ran into one that doesn't
work:
glamtools https://tools.wmflabs.org/glamtools/ is 503 but `webservice
status` says "Your webservice of type php7.3 is running".
On Thu, Jan 9, 2020 at 9:58 PM Bryan Davis wrote:
> I am happy to announce that a new and
And now I can't switch back:
...switch back commands...
tools.glamtools@tools-sgebastion-07:~$ unalias kubectl
tools.glamtools@tools-sgebastion-07:~$ webservice --backend=kubernetes
php7.3 start
Your job is already running
tools.glamtools@tools-sgebastion-07:~$ webservice stop
Your webservice is
Hi all,
I do appreciate the efforts to keep toolforge running, and that sometimes
massive changes are necessary to do this, which has implications for tool
maintainers.
I also understand that there have to be deadlines at some point, otherwise
things will never get finished.
But as I have said on
On Thu, Dec 7, 2023 at 7:26 AM Kunal Mehta wrote:
>
> Just FYI if you weren't aware, the default quotas were recently raised
> to 8CPU + 8GB total, with a max of 3CPU + 6GB per pod. (This is also
> something I ran into.)
>
Thanks, that will help! I was unaware.
>
> > - Even the current Wikitec
11 matches
Mail list logo
