BBlack added a project: Wikidata.
TASK DETAIL
https://phabricator.wikimedia.org/T124418
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: BBlack
Cc: MZMcBride, Luke081515, Denniss, aaron, faidon, Joe, ori, BBlack, Aklapper,
Wikidata-bugs, aude
BBlack added a subscriber: JanZerebecki.
TASK DETAIL
https://phabricator.wikimedia.org/T124418
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: BBlack
Cc: JanZerebecki, MZMcBride, Luke081515, Denniss, aaron, faidon, Joe, ori,
BBlack, Aklapper
BBlack added a comment.
Yeah but the rate increase we're looking at is actually in the htmlCacheUpdate
job insertion rate, regardless of magnification due to
pages-affected-per-update. I'm surprised that we don't have any logs/data as
to the source of those jobs.
TASK DETAIL
https
BBlack added a project: Traffic.
TASK DETAIL
https://phabricator.wikimedia.org/T119917
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: BBlack
Cc: BBlack, Aklapper, Smalyshev, jkroll, Wikidata-bugs, Jdouglas, aude,
Deskana, Manybubbles, Mbch331
BBlack added a subscriber: BBlack.
BBlack added a comment.
It would be best to use the header `X-Client-IP` as the notion of the client IP
address for these sorts of purposes. This is intended to resolve trusted XFF,
but has a much shorter list (intended to be improved on), whereas TrustedXFF
BBlack added a comment.
In https://phabricator.wikimedia.org/T112151#1739918, @Smalyshev wrote:
> > As Andrew said above, why not support this directly in WQDS if you have to
> > support it at all?
>
>
> Because in Blazegraph, allowing POST means allowing write requests
BBlack added a subscriber: BBlack.
BBlack added a comment.
I'm not a fan of this on a few levels:
1. As Andrew said above, why not support this directly in WQDS if you have to
support it at all? as in, let the POSTs come through the rest of the stack
unmolested, and deal with it inside WQDS
BBlack moved this task to Done on the Traffic workboard.
TASK DETAIL
https://phabricator.wikimedia.org/T107602
WORKBOARD
https://phabricator.wikimedia.org/project/board/1201/
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Joe, BBlack
Cc: jeremyb
BBlack added a comment.
The commit is staged above, but we should probably hold until the 16th or so
just in case.
TASK DETAIL
https://phabricator.wikimedia.org/T109072
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: BBlack
Cc: gerritbot
BBlack added a comment.
Ah, that makes some logical sense. We should probably stripping duplicate
_User the way we are for duplicate _Token to address the bulk of it
TASK DETAIL
https://phabricator.wikimedia.org/T109038
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings
BBlack added a comment.
Pushed a fix for deleting the duplicate centralauth_User for wikidata.org,
should be in effect globally now.
TASK DETAIL
https://phabricator.wikimedia.org/T109038
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: JanZerebecki
BBlack added a subscriber: JanZerebecki.
BBlack added a comment.
We think the workaround deployed via https://gerrit.wikimedia.org/r/231556
should fix this up well enough. It worked for @JanZerebecki who still had the
old bad cookie, which the fixup wiped out. Can others confirm?
TASK
BBlack added a comment.
Does someone have the specific details here on what cookie name to wipe on
requests to what domainname(s)?
TASK DETAIL
https://phabricator.wikimedia.org/T109038
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: BBlack
Cc
BBlack added a comment.
As best I can tell from my own testing (but I think someone with deeper insight
into the CORS change for (www|query).wikidata.org and S:UL and such would need
to confirm this sounds sane): I was able to reproduce the issue, and I was able
to apparently perma-fix
BBlack added a comment.
In https://phabricator.wikimedia.org/T107602#1507676, @JanZerebecki wrote:
If we put it in misc then this would be the first that has another level
behind misc instead of one named server. I have no preference. You or whoever
wants to merge it chooses?
Another
BBlack added a comment.
Bringing this conversation back here from the comments in
https://gerrit.wikimedia.org/r/#/c/228411/
The short summary about what this does is:
A read only mirror of Wikidata.org (only the public information) in a
special database for anyone to run queries against
BBlack added a subscriber: BBlack.
BBlack added a comment.
Do we actually need an internal service endpoint like `wdqs.svc.eqiad.wmnet`
for this, or are we just doing this as part of a standard construction for
services with multiple hosts behind public varnish/LVS need another layer of
LVS
101 - 117 of 117 matches
Mail list logo
