Some newer RfCs that you ought to know about, mostly draft-ish and in
progress. Please comment on their talkpages.
* https://www.mediawiki.org/wiki/Requests_for_comment/SOA_Authentication
"With many more entry points and the need for inter-service
authentication, a service-oriented architecture requires a stronger
authentication system."
*
https://www.mediawiki.org/wiki/Requests_for_comment/Debugging_at_production…
"Sometimes we have to debug on production wiki, but don't want to show
internal information to normal users..."
*
https://www.mediawiki.org/wiki/Requests_for_comment/Unfragmented_ZERO_design
"In order to significantly reduce varnish fragmentation and reduce the
complexity, Zero team would like to unify HTML served to all Zero
partners's users...."
Also: I've heard feedback that the RfC process ought to move faster, and
that we ought to have more people from more disciplines take a look at
changes that users will visually notice. Sounds good to me. So:
* I'm going to add more IRC discussion hours that will be more for
*discussing* specific RfCs and getting general community feedback,
rather than asking for go/no-go decisions. These will be in addition to
the weekly decision-oriented meetings. It seems like people get a lot
out of having these real-time conversations in addition to the option to
comment onwiki and onlist, so this is a way to push the most complex
topics forward. This will also allow us to have more chats that suit
different timezones. We will also sometimes piggyback them onto the
videostreamed Tech Talks, with simultaneous Etherpad notes + IRC.
* I'm going to make more of an effort to invite specific people from
diverse disciplines to RfC discussions, e.g., QA people for debugging
stuff, design/product people for user-visible changes, etc. I've been
doing this but I'll be more systematic. Please help me out by spreading
the word to people whom you think will be interested.
--
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
Ori, thanks for following up.
I think I saw somewhere that there is a list of postmortems for tech ops disruptions
that includes reports like this one. Do you know where the list is? I tried a web search
and couldn't find a copy of this report outside of this email list.
I personally find this report interesting and concise, and I am interested in
understanding more about the tech ops infrastructure. Reports like this one
are useful in building that understanding. If there's an overview of tech ops
somewhere I'd be interested in reading that too. The information on English
Wikipedia about WMF's server configuration appears to be outdated.
Thanks,
Pine
> Date: Thu, 29 May 2014 22:38:10 -0700
> From: Ori Livneh <ori(a)wikimedia.org>
> To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
> Subject: Re: [Wikitech-l] 404 errors
> Message-ID:
> <CAHXK4ByYa8ae0EVGAUFWSCrjZtAQh+sjTW6ccJ14mB8o-teSoQ(a)mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Thu, May 29, 2014 at 1:34 PM, ENWP Pine <deyntestiss(a)hotmail.com> wrote:
>
> > Hi, I'm getting some 404 errors consistently when trying to load some
> > English Wikipedia articles. Other pages load ok. Did something break?
> >
>
> TL;DR: A package update went badly.
>
> Nitty-gritty postmortem:
>
> At 20:25 (all times UTC), change Ie5a860eb9[0] ("Remove
> wikimedia-task-appserver from app servers") was merged. There were two
> things wrong with it:
>
> 1) The appserver package was configured to delete the mwdeploy and apache
> users upon removal. The apache user was not deleted because it was logged
> in, but the mwdeploy user was. The mwdeploy account was declared in Puppet,
> but there was a gap between the removal of the package and the next Puppet
> run during which the account would not be present.
>
> 2) The package included the symlinks /etc/apache2/wmf and
> /usr/local/apache/common, which were not Puppetized. These symlinks were
> unlinked when the package was removed.
>
> Apache was configured to load configuration files from /etc/apache2/wmf,
> and these include the files that declare the DocumentRoot and Directory
> directives for our sites. As a result, users were served with 404s. At
> 20:40 Faidon Liambotis re-installed wikimedia-task-appserver on all
> Apaches. Since 404s are cached in Varnish, it took another five minutes for
> the rate of 4xx responses to return to normal (20:45).[1]
>
> [0]: https://gerrit.wikimedia.org/r/#/c/136151/
> [1]:
> https://graphite.wikimedia.org/render/?title=HTTP%204xx%20responses%2C%2020…
>
Hi,
It appears that suggested search results are not being updated on English Wikipedia.
The article [[Veterans Health Administration scandal of 2014]] doesn't appear in suggested search results when I type "Veterans Health Administration", and when I searched earlier today "VA scandal" in suggested search results showed its previous redirect destination instead of its current destination, although actually clicking on "VA scandal" redirected to the correct page.
Any idea what's happening?
Thanks,
Pine
Hello,
I have created a new Jenkins job 'php-composer-validate' which invokes
'composer.json' on a proposed change and bails out whenever it is faulty.
The change is only triggered on changes that modify composer.json.
To have the job triggered on your repository, you would have to edit
Zuul configuration in integration/zuul-config.git and add an entry for
the job php-composer-validate
Example for MediaWiki core:
https://gerrit.wikimedia.org/r/#/c/136732/1/layout.yaml
Then ask for review :)
--
Antoine "hashar" Musso