Page MenuHomePhabricator

Switch all PDF render traffic to new Proton service
Open, HighPublic

Description

Proton service receives and handles 100% of production traffic, but we drop the generated PDFs. A user still receives PDF created by the old Electron PDF generator. Service proved to be stable enough to handle
all production traffic and return correct PDF files.

Acceptance criteria:

  • The Proton PDF renderer becomes default renderer
  • old Electron PDF remains on the server for some (how long?) time, just in case we have to switch back to the old service
  • RESTBase adds optional parameters supported by Proton and not Electron

Event Timeline

pmiazga created this task.Nov 28 2018, 7:54 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 28 2018, 7:54 PM
mobrovac moved this task from Backlog to next on the Services board.Nov 29 2018, 10:02 AM
mobrovac edited projects, added Services (next); removed Services.
ovasileva triaged this task as High priority.Nov 29 2018, 11:15 PM
Pchelolo updated the task description. (Show Details)

To achieve point 1, we need to

    • Refactor PDF module in RESTBase only to proxy traffic to Proton and remove the capability of split traffic, plus simplify the config.
  • See whether we would still need a js module for it, or it's possible to achieve the same result with a template-based module with no JS.
ovasileva moved this task from Triage to Backlog on the Proton board.Feb 22 2019, 3:04 PM

mediawiki-vagrant should also be updated to support new proton role.

Tgr added a subscriber: Tgr.Apr 10 2019, 7:45 PM
  • RESTBase adds optional parameters supported by Proton and not Electron

! In T210651#4936527, @Pchelolo wrote:

To achieve point 1, we need to

    • Refactor PDF module in RESTBase only to proxy traffic to Proton and remove the capability of split traffic, plus simplify the config.
  • See whether we would still need a js module for it, or it's possible to achieve the same result with a template-based module with no JS.

Do you plan to work on this or do you expect us to do it?

mediawiki-vagrant should also be updated to support new proton role.

That is T213367: Add MediaWiki-Vagrant role for Proton.

Tgr added a comment.Apr 10 2019, 7:46 PM

How would the switch itself look? Do we want some kind of staggered rollout (or rollover, I guess) with only a fraction of the users switched at first? Or not worth the effort?

We have been splitting the traffic (thus load testing Proton on real traffic) for a long time now, so the switch by now is only switching the content that's actually served to the clients. I do not think it worths making a multi-stage deployment here.

We have been splitting the traffic (thus load testing Proton on real traffic) for a long time now, so the switch by now is only switching the content that's actually served to the clients. I do not think it worths making a multi-stage deployment here.

+1. We will simply stop returning the PDF produces by Electron and start serving that of Proton.

  • RESTBase adds optional parameters supported by Proton and not Electron

! In T210651#4936527, @Pchelolo wrote:

To achieve point 1, we need to

    • Refactor PDF module in RESTBase only to proxy traffic to Proton and remove the capability of split traffic, plus simplify the config.
  • See whether we would still need a js module for it, or it's possible to achieve the same result with a template-based module with no JS.

Do you plan to work on this or do you expect us to do it?

We will be working on that.

There's already PR #1090 that addresses the issue.

The bug mentioned in T213362#5171787 is a blocker for this. It seems to break the wiki entirely if it loads external assets (which in theory no Wikimedia wiki should, but I wouldn't be surprised to find some of the less-supervised ones doing it).