Fri, Feb 15
A possible alternative is to differentiate VE's requests based on the UA header: VE sets both Api-User-Agent and User-Agent (sample RB log entry), so it is possible to recognise its requests by checking both headers and matching them against VisualEditor-Mediawiki in both Varnish and RB. This strikes me a slightly better approach than a query parameter since with the latter we can easily suffer (D)DoS attacks. Mind you, checking for headers is only sightly better, but better nevertheless.
Wed, Feb 13
Oh, ok, just wanted to make sure. Will file a new task. Thanks @Krinkle !
It seems these problems are coming back around. For EventBus Gerrit 490141 we are seeing unrelated failures for jenkins tests which fit this ticket: https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-hhvm-docker/34851/console and https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-hhvm-docker/34856/console . Is this known?
Tue, Feb 12
Mon, Feb 11
Sat, Feb 9
Fixed in master. Will be live with the next deployment of the Recommendation API service.
Fri, Feb 8
Thu, Feb 7
@Pchelolo what's different in htis task as opposed to T210651: Switch all PDF render traffic to new Proton service ? Smells like a duplicate.
Bonus points if these jobs could be created by someone adding a .pipeline/config.yaml to their project.
The TechCom will be holding an IRC meeting about this RfC next Thursday, February 14 at 07:00 UTC (08:00 CET, Feb 13 23:00 PST).
We are currently using the projects' FQDNs in MW API requests becasue this was the only way to get the CSS we needed for the printable version (not sure why that is the case, but that's a problem for another day). So, for the time being, SSL certificates are being honoured by Chromium.
Wed, Feb 6
Tue, Feb 5
@ssastry and I have briefly discussed this last week. The way the code is currently structured, it should be possible to easily separate it (and later build upon it independently). Also, no calls to MW are needed for pure lang variant conversions at the current stage, which makes this a nice and well-isolated feature. @ssastry @cscott could you confirm the above is true?
Personally, option (1) seems like a clear winner here. If done correctly, it would provide the correct abstraction layer around relational data, which would allow a way to provide support for arbitrary RDBMS systems. Moreover, in the context of making cleaner and clearer interfaces in mw-core, going with option (1) would do us a lot of good in terms of reassessing internal interfaces and those exposed to extensions and to external entities.
Mon, Feb 4
If I understand this task correctly, it seems to be a duplicate of T107196: Set up revscoring entry points in RESTBase.
Sun, Jan 27
There have been no timeouts recorded by the automatic check scripts since the deploy, so looking good. Resolving for now, let's reopen if things change.
Another alternative could be to inject the tags at the edge, before the HTML is cached. The rough workflow could be something like:
- a page is edited
- the parser reparses it
- Parsoid/PCS reconstruct their parts
- when a page is requested, if the HTML is present at the edge cache, serve it; otherwise ask for the HTML and summary and inject the needed tags.
Wed, Jan 23
Tue, Jan 22
I agree that the most likely solution to work here is option (2), i.e. getting a host to execute it from. Perhaps it could be done from mwmaint1002, but that would need to be checked with SREs.
Sat, Jan 19
All of the instances have joined the ring (thnx @fgiunchedi!) and the latest version of RESTBase is in place, so we are good. There is one problem, now, though: I can't seem to be able to pool the node back. Let's try and see what this is about before resolving the ticket.
Fri, Jan 18
That's a good idea @fgiunchedi ! +1
Jan 18 2019
Jan 17 2019
So now we should be able to get restbase1016 back into the cluster. Since we need to re-bootstrap the instances in, we can either:
Jan 16 2019
Jan 15 2019
As discussed in T177765#4867361, Proton should not have access to the internal Wikimedia network
Jan 9 2019
Jan 8 2019
@herron manager approval received. Has the request been discussed during the SRE weekly meeting?
This is a known and recurring issue where the electron service fails to respond to requests in time. I have restarted it as this usually helps, but in the long run we will be replacing in with Proton (which should happen this Q).
Jan 7 2019
Jan 4 2019
@DarTar as Baha's manager, please review and approve this request.
Jan 3 2019
I took a quick look and it seems like there were quite a few categoryMembershipChange jobs that failed with the message Could not find page #<page_id>, which would suggest a race condition. However, the real surge in the number of log entries are for Old event processed for the same type of job. This could suggest a subtle bug in CP-JobQueue. Sample log entry:
Dec 31 2018
Dec 28 2018
Dec 27 2018
RESTBase has been deployed. Resolving.
Dec 26 2018
Ok, I tracked down the problem to the kad library. In order to have the fix in place, the following patches need to be merged (in this order):