In T198810#4945626, @greg wrote:

Email sent. Deadline of March 11th.

Change 489947 had a related patch set uploaded (by Andrew Bogott; owner: Andrew Bogott):
[operations/puppet@production] bootstrap-vz: set up a root terminal on S1

Ya:

will adding a company name filter do the work ?

What's going on here?

In T215704#4946147, @bd808 wrote:

In T215704#4943175, @Dvorapa wrote:

BTW I don't know if you know, but multiple toolforge users got all their cron jobs, grid jobs and webservices cancelled in 7th February with no warning on Trusty. So kmlexport and mapycz were down for cca 24 hours (and T215704 didn't help to me) and multiple cswiki maintenance robots are down since then too. Also without any fix from your webservices monitoring. That's why I decided to move my tools to Stretch directly the day after, because everything was down so why wait.

I did not know, apparently because no one filed a bug or reported this in the #wikimedia-cloud irc channel. I have looked through our SAL logging, email alerts, and irc logs and do not see an obvious reason for mass job failures. I can understand why an unplanned outage would make you want to look at better monitoring solutions, but I can't help fix problems that nobody reports either.

OOUI uses a build step.

I really wish it did not. The build process makes testing OOUI patches with MediaWiki a major chore.

The build step only involves concatenating JS files, compiling Less files, and generating colored icon variants, all of which are also available in MediaWiki's ResourceLoader. It could probably be refactored to avoid the build step.

I noticed that we've been having high cpu usage at about this time every day, unsure if this is some cleanup or indexing that is run on a schedule.

In T212892#4944350, @TBolliger wrote:

I spoke with upstream who said another user had reported that ( its a locking issue ) they tryed to fix it with a another library but that didn’t work.

maybe this will be illuminating for someone -- it is stack traces from the gerrit jvm process at the time it was guzzling CPU

I don't know enough about the 'map' parameter to consider any behaviors that are needed or any edge cases to say how difficult it is to implement.

@thcipriani restarted gerrit. Keeping this task open for now.

@Prtksxna I just realized there are a couple of more things to take out, if it's not too much trouble. They are in the Per-Wiki Metrics section. The following metrics were dropped:

IIRC, in some mobile browsers, the unload event doesn't fire before the JavaScript VM is torn down after a tab is closed. However, we're more confident that the visibilitychange event does fire

Anything I missed to get these projects created? :)

@RHo -- could you double-check your desktop mockup? It looks like the email field is missing.

@jcrespo Given the analysis you already did on T212092#4934152 would you recommend that we go ahead with creating this index? (If I understand your comment there, the index would be beneficial for a search only on agent and timestamp, with no restrictions on IP).

A note for when we are ready to finalize the copy for this: I think we should think of a way to indicate that adding an email is not just for account recovery -- it's also the way to find out when important/relevant things happen on the wiki. One of the reasons the Growth team is addressing this idea is because we believe that when newcomers find out what's going on in the wiki, they are more likely to come back and keep editing. We should be upfront about that to the user.

I am going to decline this Task, per the analysis done in T212092

Thanks @jcrespo

A note for when we are ready to finalize the copy for this: I think we should think of a way to indicate that adding an email is not just for account recovery -- it's also the way to find out when important/relevant things happen on the wiki. One of the reasons the Growth team is addressing this idea is because we believe that when newcomers find out what's going on in the wiki, they are more likely to come back and keep editing. We should be upfront about that to the user.

I think the logic warranted is sufficiently simple that the cheapest and most sustainable approach (in terms of maintenance cost, bandwidth, and run-time overhead), is to inline this utility in code bases that need it.

Friday is ok to me, that way I'll have the weekend to fix something that needs to be changed

In T215704#4943175, @Dvorapa wrote:

BTW I don't know if you know, but multiple toolforge users got all their cron jobs, grid jobs and webservices cancelled in 7th February with no warning on Trusty. So kmlexport and mapycz were down for cca 24 hours (and T215704 didn't help to me) and multiple cswiki maintenance robots are down since then too. Also without any fix from your webservices monitoring. That's why I decided to move my tools to Stretch directly the day after, because everything was down so why wait.

Yep. I'll have a dig into this later today, maybe add some more tests with the above parameters. Thanks @dom_walden for finding this.

@Jdlrobson - please review the following.
Testing on betalabs:
(1) The state is of 'Thank' button does not persists - click on 'Thanks' , wait for the confirmation and finishing of the action (grey 'Thanked' button), go to the next edit, return - the 'Thank' button will be active again. Also, the desktop and mobile do not sync - actions on the desktop are not reflected on mobile.

I've scheduled the above patch for deployment on Thursday February 14 at 00:00-01:00 UTC (Wednesday 16:00-17:00).

Moved to blocked until I hear back on i18n ticket I filed https://phabricator.wikimedia.org/T215854

In T215704#4946110, @bd808 wrote:

In T215704#4943172, @Dvorapa wrote:

I could not make webservices --backend=kubernetes start work here. Neither for mapycz, nor for kmlexport. In mapycz there is probably .kube folder missing, in kmlexport it fails with T214343

The missing $HOME/.kube directory for mapycz is not a problem I was aware of. I can see that there is a token in the Kubernetes auth control file for this tool, so either there was a crash at the time it was generated or someone deleted the directory at some point. I will try to fix that.

Follow up adding test and fixing other issues the test surfaced:
https://github.com/wikimedia/wikipedia-ios/pull/2907

Change 489928 merged by jenkins-bot:
[mediawiki/extensions/Kartographer@master] Fix typo in api i18n message

Change 489934 had a related patch set uploaded (by Catrope; owner: Catrope):
[operations/mediawiki-config@master] Enable ORES (damaging-only) on itwiki

Mentioned in SAL (#wikimedia-cloud) [2019-02-12T01:24:52Z] <bd808> Stopped maintain-kubeusers, edited /etc/kubernetes/tokenauth, restarted maintain-kubeusers (T215704)

In T215704#4943172, @Dvorapa wrote:

I could not make webservices --backend=kubernetes start work here. Neither for mapycz, nor for kmlexport. In mapycz there is probably .kube folder missing, in kmlexport it fails with T214343

Production hasn't been updated with this yet. I forgot to move this to QA when the patch was merged. Doing so now. Test with e.g. https://tools.wmflabs.org/svgtranslate-test/File:Speech_bubbles.svg

Patch merged.

Change 489929 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/extensions/PageViewInfo@master] Skip invalid titles from pageview API in ApiQueryMostViewed

@Axon-x have I captured your request correctly? Is the problem here that the text is hard to read? For instance if we supported a larger font size in the previews would that solve the problem you are facing?

Change 489928 had a related patch set uploaded (by Reedy; owner: Reedy):
[mediawiki/extensions/Kartographer@master] Fix typo in api i18n message

Need to investigate setting up a read-only user for RAPI in ganeti if we want a sync program that runs without privileges.

Internal API equivalent : cl.Query(ganeti.constants.QR_INSTANCE, ['name','os','status','mac','ip','be/maxmem','vcpus','disk.sizes','tags'], ganeti.qlang.MakeSimpleFilter('name', None)).data where cl is initialized form ganeti.cli.GetClient