Page MenuHomePhabricator

Remove (?) l10nupdate from !log'ing
Closed, DeclinedPublic

Description

Summary:

  • Greg noticed l10nupdate !log messages saying "failed" via the @wikimediatech twitter account (which echos the SAL)
  • Bug gets fixed etc etc
  • Topic comes up to remove l10nupdate messages from !log'ing in SAL as they are noisy

Proposal:

Event Timeline

greg raised the priority of this task from to Needs Triage.
greg updated the task description. (Show Details)
greg added a project: Deployments.
greg added subscribers: greg, ori.
greg set Security to None.
greg added subscribers: mmodell, demon, thcipriani.

We should probably get some input from SRE on this one.

I think we should keep it !log'ing. We log all MediaWiki code deploys through scap, and l10nupdate shouldn't be an exception.

Ok, repurposing this task for whether or not we should remove it from !log'ing.

I still think alerting (more than just a !log) is needed for the l10nupdate, though, since it's automatic and happens when most people are not online.

greg renamed this task from Setup l10nupdate alerts to remove l10nupdate from !log'ing to Remove (?) l10nupdate from !log'ing.Jul 30 2015, 10:30 PM
greg updated the task description. (Show Details)
greg updated the task description. (Show Details)

I'd like to continue getting l10nupdate updates on the !log lines that flow to the #wikimedia-operations channel (or equivalent) if we can. It's good for correlating with any related issues, and I suspect even now l10update timing may be related to some difficult-to-track down low-impact issues we've been investigating for a while with timeout spikes from mw->varnish for Main_Page, etc...

thcipriani triaged this task as Medium priority.Aug 5 2015, 4:07 PM
thcipriani moved this task from To Triage to Next: Maintenance on the Deployments board.

I think we should keep it !log'ing. We log all MediaWiki code deploys through scap, and l10nupdate shouldn't be an exception.

+1
Given LocalisationUpdate failures are usually noticed by translators rather than sysadmins/devs/whatever, SAL is the most reasonable place.

As for the noise, this proposal appears to be a (non|wrong) solution for T49301.

greg claimed this task.

Declining based on consensus.